From lr at pcorp.us Tue Sep 8 14:39:10 2026 From: lr at pcorp.us (Regina Obe) Date: Tue, 8 Sep 2026 17:39:10 -0400 Subject: PostGIS 3.7.0rc2 released Message-ID: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> The PostGIS Team is pleased to release PostGIS 3.7.0rc2! Best Served with PostgreSQL 19 Beta 3 , GEOS 3.15.0 , This version requires PostgreSQL 14 - 19beta3, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed. This release contains fixes since 3.7.0rc1 release. Details at: https://postgis.net/2026/09/PostGIS-3.7.0rc2/ Source: https://download.osgeo.org/postgis/source/postgis-3.7.0rc2.tar.gz PDF En: https://download.osgeo.org/postgis/docs/postgis-3.7.0rc2-en.pdf HTML: https://download.osgeo.org/postgis/docs/doc-html-3.7.0rc2.tar.gz NOTE: postgis_tiger_geocoder and address_standardizer are no longer part of the PostGIS source code. Latest release of postgis_tiger_geocoder is noted - https://postgis.net/2026/08/PostGIS-Tiger-Geocoder-2025.2/ address_standardizer latest version is https://github.com/postgis/address_standardizer/releases/tag/v3.7.0 , but a 4.0.0 will be released around the same time or shortly after PostGIS 3.7.0. If you run into any issues, feel free to reply to this email or report on our ticket tracker as detailed on https://postgis.net/development/bug_reporting/ Thanks, PostGIS Development Team From gdt at lexort.com Tue Sep 8 17:14:28 2026 From: gdt at lexort.com (Greg Troxel) Date: Tue, 08 Sep 2026 20:14:28 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> (Regina Obe's message of "Tue, 8 Sep 2026 17:39:10 -0400") References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: docs build still fails with a non-built complaint, without any errors reported from doing the docs build. It's therefore hard to debug. It also doesn't make sense why a directory "regress" would be involved in building docs. gmake[1]: Entering directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2' /usr/pkg/bin/perl ./utils/repo_revision.pl fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Can't determine revision from git log Not updating existing rev file at e2ea03a /tmp/work/databases/postgresql-postgis2.update/work/.tools/bin/gmake -C doc html gmake[2]: Entering directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/doc' Makefile:626: *** Visual examples are missing. Run 'make -C regress visual-examples' first.. Stop. gmake[2]: Leaving directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/doc' gmake[1]: *** [GNUmakefile:251: docs] Error 2 gmake[1]: Leaving directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2' gmake: *** [Makefile:7: docs] Error 2 *** Error code 2 Reading NEWS: To build docs, first run visual examples and make sure you have a running PostgreSQL instance. `make -C regress visual-examples` this is really problematic and outside the normal boundaries. - "run visual examples" does not parse - "make sure you have a running postgresql instance" is not ok. When building packages, they're in a sandbox and while package building machines do run build tools, but requiring someone to start up a database is way too much for this kind of environment - "build docs" and "regress" do not belong together I see in README.postgis description of doc requirements and will crosscheck that. I think there's a makefile bug where missing prereqs lead to steps being skipped, instead of erroring. Perhaps pgsql is run within the build temporarily, like regression tests do. That's still not great for docs, but it's less problematic than expecting db setup I'll look into this before, but I wanted to test/write quickly that rc2 is not suitable for release. I hope these issues are relatively easy to address. From gdt at lexort.com Tue Sep 8 17:30:31 2026 From: gdt at lexort.com (Greg Troxel) Date: Tue, 08 Sep 2026 20:30:31 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: (Greg Troxel's message of "Tue, 08 Sep 2026 20:14:28 -0400") References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: I think I understand better now. * details rsvg-convert is listed as needed, but configure.ac doesn't look for it. It does look for convert, but doesn't check that it does what you need - I'm unclear on if a working convert always does, or if it's optional. * big picture Within the "make docs" top-level target there are a lot of subsidiary docs targets. Some of them fall into "things a package ought to have installed", and some seem more obscure. In packaging, what I want is a way to ask for the things that belong in a package. If visual examples require things that aren't compatible with packaging build environments, I'm ok with having those be off. Looking in doc/Makefile I see ifeq ($(CAN_BUILD_COMMENTS),yes) BUILD_TARGET += comments endif ifeq ($(CAN_BUILD_PDF),yes) BUILD_TARGET += pdf endif ifeq ($(CAN_BUILD_EPUB),yes) BUILD_TARGET += epub endif but I see no such if for visual examples. Perhaps that's the problem, or perhaps there should be split targets from top-level, or make docs removed and documented which targets should be called, for things to be "make installed". I admit to not paying attention to doc details; for years things have built and the binary package has man pages. (I don't want to depend on latex.) From lr at pcorp.us Tue Sep 8 18:00:24 2026 From: lr at pcorp.us (Regina Obe) Date: Tue, 8 Sep 2026 21:00:24 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> > I think I understand better now. > > * details > > rsvg-convert is listed as needed, but configure.ac doesn't look for it. > It does look for convert, but doesn't check that it does what you need - I'm > unclear on if a working convert always does, or if it's optional. > Hmm that shouldn't be needed. My understanding is that it is preferred but not required if you have ImageMagick or GraphMagick Darafei can you confirm? I have neither locally. > * big picture > > Within the "make docs" top-level target there are a lot of subsidiary docs > targets. Some of them fall into "things a package ought to have installed", and > some seem more obscure. In packaging, what I want is a way to ask for the > things that belong in a package. If visual examples require things that aren't > compatible with packaging build environments, I'm ok with having those be > off. > > Looking in doc/Makefile I see > > ifeq ($(CAN_BUILD_COMMENTS),yes) > BUILD_TARGET += comments > endif > The comments build doesn't need visual examples. Are you having trouble building that? I can revisit that to make sure I didn't screw that up when I made changes to the visual examples thing. > ifeq ($(CAN_BUILD_PDF),yes) > BUILD_TARGET += pdf > endif > > ifeq ($(CAN_BUILD_EPUB),yes) > BUILD_TARGET += epub > endif > > but I see no such if for visual examples. Perhaps that's the problem, or > perhaps there should be split targets from top-level, or make docs removed > and documented which targets should be called, for things to be "make > installed". > > I admit to not paying attention to doc details; for years things have built and > the binary package has man pages. (I don't want to depend on > latex.) PDF and epub do require visual examples but those should be tested now and should be cleanly erroring if you haven't built the visual examples. For the most part we haven't been worried too much about docs as long as our CI that packages releases can build them. I think most packagers just use our pre-built docs: Which for this release - https://postgis.net/stuff/postgis-3.7-en.pdf and https://download.osgeo.org/postgis/docs/doc-html-3.7.0rc2.tar.gz Though I realize now I never bothered to link the html ones, probably cause I take it for granted people would just read them online or use the pdf for offline use which are always listed here for our supported versions - https://postgis.net/documentation/manual/ Users I suspect don't care about building docs if they are building for themselves and frankly our build chain especially now that we have translations Is very complicated and has always been complicated (perhaps a bit more so with the introduction of our (lets make sure our docs reflect our changes in the branch) which is why we have this new fangled visual examples build that actually tests our doc examples to generate the images. I wouldn't want any packager to waste time trying to get all the glue to make that work unless they have a pressing requirement to do so. It's best just downloaded and installed. From lr at pcorp.us Tue Sep 8 18:38:54 2026 From: lr at pcorp.us (Regina Obe) Date: Tue, 8 Sep 2026 21:38:54 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: <000001dd3ffb$fb0f5490$f12dfdb0$@pcorp.us> > docs build still fails with a non-built complaint, without any errors > reported from doing the docs build. It's therefore hard to debug. > It also doesn't make sense why a directory "regress" would be involved in > building docs. > > gmake[1]: Entering directory '/tmp/work/databases/postgresql- > postgis2.update/work/postgis-3.7.0rc2' > /usr/pkg/bin/perl ./utils/repo_revision.pl > fatal: not a git repository (or any parent up to mount point /) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > set). > Can't determine revision from git log > Not updating existing rev file at e2ea03a > /tmp/work/databases/postgresql-postgis2.update/work/.tools/bin/gmake -C > doc html > gmake[2]: Entering directory '/tmp/work/databases/postgresql- > postgis2.update/work/postgis-3.7.0rc2/doc' > Makefile:626: *** Visual examples are missing. Run 'make -C regress visual- > examples' first.. Stop. > gmake[2]: Leaving directory '/tmp/work/databases/postgresql- > postgis2.update/work/postgis-3.7.0rc2/doc' > gmake[1]: *** [GNUmakefile:251: docs] Error 2 > gmake[1]: Leaving directory '/tmp/work/databases/postgresql- > postgis2.update/work/postgis-3.7.0rc2' > gmake: *** [Makefile:7: docs] Error 2 > *** Error code 2 > The compile error is just bogus. Stems from the fact that visual-examples aren't built. On my system I get this now from building from the tarball and running commands: make -C doc html wrote /projects/postgis/postgis-3.7.0rc2/doc/html/postgis-ref-index.json and /projects/postgis/postgis-3.7.0rc2/doc/html/postgis-ref-index.js; commands=1, functions=630, operator pages=37, SQL keywords=63 Makefile:626: *** Visual examples are missing. Run 'make -C regress visual-examples' first.. Stop. make: Leaving directory '/projects/postgis/postgis-3.7.0rc2/doc' Which I felt was much clearer than it recursing on each step and failing cause it couldn't find the images. Not sure why yours continues to recurse on. Before I made the change to the steps to just exit, I was getting the same results you were. > Reading NEWS: > > To build docs, first run visual examples and make sure you have a running > PostgreSQL instance. > > `make -C regress visual-examples` > > this is really problematic and outside the normal boundaries. > > - "run visual examples" does not parse > - "make sure you have a running postgresql instance" is not ok. When > building packages, they're in a sandbox and while package building > machines do run build tools, but requiring someone to start up a > database is way too much for this kind of environment > - "build docs" and "regress" do not belong together > You need a running PostgreSQL to regress test don't you? I fail to see the issue here. But yes our image examples are doing double duty of testing the documentation and building the images. pgRouting also follows this -- though their doc queries just output results not the images and those results are included in the docs. https://github.com/pgRouting/pgrouting/tree/develop/docqueries > > I see in README.postgis description of doc requirements and will > crosscheck that. I think there's a makefile bug where missing prereqs > lead to steps being skipped, instead of erroring. > > > Perhaps pgsql is run within the build temporarily, like regression tests do. > That's still not great for docs, but it's less problematic than expecting db setup > > > I'll look into this before, but I wanted to test/write quickly that rc2 is not > suitable for release. I hope these issues are relatively easy to address. Yah I was debating that but I feared trying to change that would just break things in more vulnerable ways. Do you agree the best course of action is just to advice people to NOT try to build docs unless they are contributing to the project and just make it very clear where they can download them pre-built? Even if contributing I'd probably say it's not necessary as I document a lot and never have had a need to build the docs myself. Always relied on the CI to do that. From sebastic at xs4all.nl Tue Sep 8 22:33:19 2026 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Wed, 9 Sep 2026 07:33:19 +0200 Subject: PostGIS 3.7.0rc2 released In-Reply-To: <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> Message-ID: On 9/9/26 3:00 AM, Regina Obe wrote: > Hmm that shouldn't be needed. My understanding is that it is preferred but > not required if you have ImageMagick or GraphMagick The Debian package stopped building the docs because it fails with newer ImageMagick: https://trac.osgeo.org/postgis/ticket/5593 We haven't bothered to re-enable the docs build after the changes at the end of that ticket. -- PGP Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 From gdt at lexort.com Wed Sep 9 05:39:50 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 09 Sep 2026 08:39:50 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> (Regina Obe's message of "Tue, 8 Sep 2026 21:00:24 -0400") References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> Message-ID: "Regina Obe" writes: >> I think I understand better now. >> >> * details >> >> rsvg-convert is listed as needed, but configure.ac doesn't look for it. >> It does look for convert, but doesn't check that it does what you need - > I'm >> unclear on if a working convert always does, or if it's optional. > > Hmm that shouldn't be needed. My understanding is that it is preferred but > not required if you have ImageMagick or GraphMagick > Darafei can you confirm? I have neither locally. "convert" is part of ImageMagick. My point is that if the build is maybe going to use rsvg-convert, it should probably be checked for by configure and listed in the configure results. The only thing that's obvious here is that the docs build process is too complicated and too hard to understand. >> * big picture >> >> Within the "make docs" top-level target there are a lot of subsidiary docs >> targets. Some of them fall into "things a package ought to have > installed", and >> some seem more obscure. In packaging, what I want is a way to ask for the >> things that belong in a package. If visual examples require things that > aren't >> compatible with packaging build environments, I'm ok with having those be >> off. >> >> Looking in doc/Makefile I see >> >> ifeq ($(CAN_BUILD_COMMENTS),yes) >> BUILD_TARGET += comments >> endif >> > The comments build doesn't need visual examples. Are you having trouble > building that? I am getting an error doing "make docs" from top-level. The build instructions are unclear about what kinds of docs there are. > I can revisit that to make sure I didn't screw that up when I made changes > to the visual examples thing. There seems to be a clear regression with 3.7.0 > PDF and epub do require visual examples but those should be tested now and > should be cleanly erroring if you haven't built the visual examples. I ran 'make docs'. Perhaps the real issue is this concept of a manual build step for visual examples. There should not be any manual build steps! > For the most part we haven't been worried too much about docs as long as our > CI that packages releases can build them. I don't see that as the right approach. Everything should work, everywhere, and the point of CI is to verify that. Of course CI is incomplete and things slip through, but that sounds like "if it builds in our CI, it's not a bug". > I think most packagers just use our pre-built docs: > Which for this release - https://postgis.net/stuff/postgis-3.7-en.pdf and > https://download.osgeo.org/postgis/docs/doc-html-3.7.0rc2.tar.gz > > Though I realize now I never bothered to link the html ones, probably cause > I take it for granted people would just read them online or use the pdf for > offline use which > are always listed here for our supported versions - > https://postgis.net/documentation/manual/ I see open-source norms as requiring: - documentation should be part of packages so it's available without the net - built docs are binaries and anyone must be able to build docs from the doc sources - all of this should be encapsulated in a build procedure that does not require manual steps > Users I suspect don't care about building docs if they are building for > themselves and frankly our build chain especially now that we have > translations > Is very complicated and has always been complicated (perhaps a bit more so > with the introduction of our (lets make sure our docs reflect our changes in > the branch) which is why we have this new fangled visual examples build that > actually tests our doc examples to generate the images. I wouldn't want any > packager to waste time trying to get all the glue to make that work unless > they have a pressing requirement to do so. > It's best just downloaded and installed. That sounds like "this is open source in name only; just use our docker container"! From gdt at lexort.com Wed Sep 9 05:45:08 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 09 Sep 2026 08:45:08 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: <000001dd3ffb$fb0f5490$f12dfdb0$@pcorp.us> (Regina Obe's message of "Tue, 8 Sep 2026 21:38:54 -0400") References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> <000001dd3ffb$fb0f5490$f12dfdb0$@pcorp.us> Message-ID: "Regina Obe" writes: > The compile error is just bogus. Stems from the fact that visual-examples > aren't built. > On my system I get this now from building from the tarball and running > commands: > > make -C doc html > > wrote /projects/postgis/postgis-3.7.0rc2/doc/html/postgis-ref-index.json and > /projects/postgis/postgis-3.7.0rc2/doc/html/postgis-ref-index.js; > commands=1, functions=630, operator pages=37, SQL keywords=63 > Makefile:626: *** Visual examples are missing. Run 'make -C regress > visual-examples' first.. Stop. > make: Leaving directory '/projects/postgis/postgis-3.7.0rc2/doc' > > Which I felt was much clearer than it recursing on each step and failing > cause it couldn't find the images. This follows from the bug that make docs doesn't build them. > Not sure why yours continues to recurse on. Before I made the change to the > steps to just exit, I was getting the same results you were. I don't think it does continue. >> Reading NEWS: >> >> To build docs, first run visual examples and make sure you have a > running >> PostgreSQL instance. >> >> `make -C regress visual-examples` >> >> this is really problematic and outside the normal boundaries. >> >> - "run visual examples" does not parse >> - "make sure you have a running postgresql instance" is not ok. When >> building packages, they're in a sandbox and while package building >> machines do run build tools, but requiring someone to start up a >> database is way too much for this kind of environment >> - "build docs" and "regress" do not belong together >> > > You need a running PostgreSQL to regress test don't you? I fail to see the > issue here. Yes, to run regression tests. But we are not talking about running regression tests; we are talking about building documentation. >> I'll look into this before, but I wanted to test/write quickly that >> rc2 is not suitable for release. I hope these issues are relatively >> easy to address. > > Yah I was debating that but I feared trying to change that would just break > things in more vulnerable ways. > Do you agree the best course of action is just to advice people to NOT try > to build docs unless they are contributing to the project > and just make it very clear where they can download them pre-built? No, I don't think that's reasonable. This is a regression from the previous stable branch. > Even if contributing I'd probably say it's not necessary as I document a lot > and never have had a need to build the docs myself. Always relied on the CI > to do that. That's the slippery slope to thinking telling people to run docker containers is ok. Seriously, I see a lot of projects that claim to be open source and then say "This is too hard to build. Just use our docker container", and seem to not perceive that as a serious project bug. From gdt at lexort.com Wed Sep 9 06:24:22 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 09 Sep 2026 09:24:22 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> (Regina Obe's message of "Tue, 8 Sep 2026 17:39:10 -0400") References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: After avoiding docs build, the good news is that regression tests mostly pass. The 'fuzzers' test fails, and I think the problem is non-POSIX use of cp, but I was unable to locate it precisely. It might be build_google_oss_fuzzers.sh: cp --update=none "$lib" "$OUT/lib/" || true POSIX specification for cp: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/cp.html I'm testing on NetBSD 10 amd64, and I have never heard of cp having an option "--update". I suspect that's only in some GNU/Linux versions. macOS 15 does not document it in the man page, and and macOS 26 doesn't either. I am pretty sure this is also a regression from 3.6.0, but I can't swear I ran tests for that. test snippet follows: (the c++ version complaint is a symptom of many programs requiring new C++ stds, and is super unlikely to be related to the cp complaint) mkdir -p fuzzers fuzzer_out=`mktemp -d "${TMPDIR:-/tmp}/postgis-fuzzer-check.XXXXXX"`; \ trap 'rm -rf "${fuzzer_out}"' EXIT HUP INT TERM; \ /tmp/work/databases/postgresql-postgis2.update/work/.tools/bin/gmake -C fuzzers -f /tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers/Makefile \ POSTGIS_BUILD_DIR="/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2" \ FUZZER_OUT="${fuzzer_out}" \ check gmake[2]: Entering directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers' gmake[3]: Entering directory '/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers' gcc -O2 -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -c -o fuzzingengine.o /tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers/fuzzingengine.c mkdir -p "/tmp/postgis-fuzzer-check.VOFejp" ar r libFuzzingEngine.a fuzzingengine.o ar: creating libFuzzingEngine.a CC="gcc" CXX="c++" CPPFLAGS=" -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/json-c -DNDEBUG -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2" CXXFLAGS="-L/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers -O2 -I/usr/pkg/include -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2" LDFLAGS=" -Wl,-zrelro -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -lexecinfo -lm -L/usr/pkg/lib -lgeos_c -L/usr/pkg/lib -lproj -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -ljson-c -Wl,-zrelro -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -lexecinfo" POSTGIS_BUILD_DIR="/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2" SRC="/tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers" OUT="/tmp/postgis-fuzzer-check.VOFejp" /tmp/work/databases/postgresql-postgis2.update/work/postgis-3.7.0rc2/fuzzers/build_google_oss_fuzzers.sh Building fuzzer encoded_polyline_import_fuzzer Building fuzzer geohash_import_fuzzer Building fuzzer geojson_import_fuzzer Building fuzzer gserialized_from_bytea_fuzzer Building fuzzer gserialized_from_lwgeom_fuzzer Building fuzzer twkb_import_fuzzer Building fuzzer wkb_import_fuzzer Building fuzzer wkt_import_fuzzer Building fuzzer raster_deserialize_fuzzer ld: warning: libstdc++.so.7, needed by /usr/pkg/lib/libpoppler.so.161, may conflict with libstdc++.so.9 ld: warning: libstdc++.so.7, needed by /usr/pkg/lib/libpoppler.so.161, may conflict with libstdc++.so.9 cp: unknown option -- - usage: cp [-R [-H | -L | -P]] [-f | -i] [-alNpv] src target cp [-R [-H | -L | -P]] [-f | -i] [-alNpv] src1 ... srcN directory cp: unknown option -- - usage: cp [-R [-H | -L | -P]] [-f | -i] [-alNpv] src target cp [-R [-H | -L | -P]] [-f | -i] [-alNpv] src1 ... srcN directory From gdt at lexort.com Wed Sep 9 07:16:25 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 09 Sep 2026 10:16:25 -0400 Subject: longer EPSG WKT2 Message-ID: EPSG now has an ensemble for ETRS89 and those have many members, e.g. https://epsg.org/crs/wkt/id/25830 which are well beyond the 2048 size in the table definition. I therefore wonder: What version of the EPSG database does postgis come with (seems hard to find in NEWS?)? What is the relationship between the postgis EPSG version and the proj EPSG version? Should the table fields become larger? Perhaps 16384? and If postgis depends on proj, why isn't it just using the EPSG database from proj? (This issue was raised by Javier on the proj list.) From lr at pcorp.us Wed Sep 9 07:42:00 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 10:42:00 -0400 Subject: longer EPSG WKT2 In-Reply-To: References: Message-ID: <009201dd4069$5fe686f0$1fb394d0$@pcorp.us> > EPSG now has an ensemble for ETRS89 and those have many members, e.g. > > https://epsg.org/crs/wkt/id/25830 > > which are well beyond the 2048 size in the table definition. > > I therefore wonder: > > What version of the EPSG database does postgis come with (seems hard > to find in NEWS?)? > > What is the relationship between the postgis EPSG version and the proj > EPSG version? > > Should the table fields become larger? Perhaps 16384? > > and > > If postgis depends on proj, why isn't it just using the EPSG database > from proj? > > > (This issue was raised by Javier on the proj list.) It is mostly just using the proj.db. Anything beyond storage of srid and auth_srid is considered legacy use in PostGIS. PostGIS always checks proj.db for core definitions if the auth_srid exists in the proj.db. The srtext / proj4text is only used of the definitions don't exist in proj.db. We've had this debate for a while if PostGIS should just come with an essentially empty spatial_ref_sys and as part of user responsibility load what they need to load from proj.db and even making spatial_ref_sys a view that just wraps a function that reads from proj.db. That would largely solve the issue with have with pg_upgrade that in some cases tables are loaded before spatial_ref_sys is populated. There was discussion that editing the proj.db is harder to edit than the spatial_ref_sys for users wanting to define their own custom projection, so that was the big boo against getting rid of spatial_ref_sys as a table. Other reason is it would probably kill performance. From lr at pcorp.us Wed Sep 9 07:53:54 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 10:53:54 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> Message-ID: <009c01dd406b$09769e70$1c63db50$@pcorp.us> > After avoiding docs build, the good news is that regression tests mostly pass. > > The 'fuzzers' test fails, and I think the problem is non-POSIX use of cp, but I > was unable to locate it precisely. It might be > > build_google_oss_fuzzers.sh: cp --update=none "$lib" "$OUT/lib/" || > true > > POSIX specification for cp: > > https://pubs.opengroup.org/onlinepubs/9799919799/utilities/cp.html > > I'm testing on NetBSD 10 amd64, and I have never heard of cp having an > option "--update". I suspect that's only in some GNU/Linux versions. > macOS 15 does not document it in the man page, and and macOS 26 doesn't > either. > > I am pretty sure this is also a regression from 3.6.0, but I can't swear I ran > tests for that. > Strange we do test MacOS and MacOS didn't raise an issue on this. https://github.com/postgis/postgis/actions/runs/34330333884/job/102397171918 Though I admit to being out of my depth with BSDs. From lr at pcorp.us Wed Sep 9 08:15:39 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 11:15:39 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> Message-ID: <00a201dd406e$12ecc530$38c64f90$@pcorp.us> > From: Sebastiaan Couwenberg via postgis-users On 9/9/26 3:00 AM, Regina Obe wrote: > > Hmm that shouldn't be needed. My understanding is that it is > > preferred but not required if you have ImageMagick or GraphMagick > > The Debian package stopped building the docs because it fails with newer > ImageMagick: > > https://trac.osgeo.org/postgis/ticket/5593 > > We haven't bothered to re-enable the docs build after the changes at the end > of that ticket. > > -- > PGP Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 This is a bit concerning. I'll double-check this but we did put in fixes so ImageMagick or GraphMagick can be used. https://gitea.osgeo.org/postgis/postgis/commit/95e8afa Though now I notice that was for the old image building logic which we later ripped out. Though with the new setup any of those should still be supported per https://gitea.osgeo.org/postgis/postgis/src/branch/master/doc/html/images/Makefile.in#L56 From lr at pcorp.us Wed Sep 9 08:30:23 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 11:30:23 -0400 Subject: PostGIS 3.7.0rc2 released In-Reply-To: References: <001101dd3fda$7c978c70$75c6a550$@pcorp.us> <002001dd3ff6$99a3b390$cceb1ab0$@pcorp.us> Message-ID: <00a301dd4070$22640d00$672c2700$@pcorp.us> > From: Greg Troxel > Sent: Wednesday, September 9, 2026 8:40 AM > To: Regina Obe > Cc: postgis-users at lists.osgeo.org; 'Darafei \"Kom?pa\" Praliaskouski' > > Subject: Re: PostGIS 3.7.0rc2 released > > "Regina Obe" writes: > > >> I think I understand better now. > >> > >> * details > >> > >> rsvg-convert is listed as needed, but configure.ac doesn't look for it. > >> It does look for convert, but doesn't check that it does what you > >> need - > > I'm > >> unclear on if a working convert always does, or if it's optional. > > > > Hmm that shouldn't be needed. My understanding is that it is > > preferred but not required if you have ImageMagick or GraphMagick > > Darafei can you confirm? I have neither locally. > > "convert" is part of ImageMagick. > > My point is that if the build is maybe going to use rsvg-convert, it should > probably be checked for by configure and listed in the configure results. The > only thing that's obvious here is that the docs build process is too complicated > and too hard to understand. > > > >> * big picture > >> > >> Within the "make docs" top-level target there are a lot of subsidiary > >> docs targets. Some of them fall into "things a package ought to have > > installed", and > >> some seem more obscure. In packaging, what I want is a way to ask > >> for the things that belong in a package. If visual examples require > >> things that > > aren't > >> compatible with packaging build environments, I'm ok with having > >> those be off. > >> > >> Looking in doc/Makefile I see > >> > >> ifeq ($(CAN_BUILD_COMMENTS),yes) > >> BUILD_TARGET += comments > >> endif > >> > > The comments build doesn't need visual examples. Are you having > > trouble building that? > > I am getting an error doing "make docs" from top-level. The build instructions > are unclear about what kinds of docs there are. > > > I can revisit that to make sure I didn't screw that up when I made > > changes to the visual examples thing. > > There seems to be a clear regression with 3.7.0 > > > PDF and epub do require visual examples but those should be tested now > > and should be cleanly erroring if you haven't built the visual examples. > > I ran 'make docs'. Perhaps the real issue is this concept of a manual build step > for visual examples. There should not be any manual build steps! > > > For the most part we haven't been worried too much about docs as long > > as our CI that packages releases can build them. > > I don't see that as the right approach. Everything should work, everywhere, > and the point of CI is to verify that. Of course CI is incomplete and things slip > through, but that sounds like "if it builds in our CI, it's not a bug". > > > I think most packagers just use our pre-built docs: > > Which for this release - https://postgis.net/stuff/postgis-3.7-en.pdf > > and https://download.osgeo.org/postgis/docs/doc-html-3.7.0rc2.tar.gz > > > > Though I realize now I never bothered to link the html ones, probably > > cause I take it for granted people would just read them online or use > > the pdf for offline use which are always listed here for our supported > > versions - https://postgis.net/documentation/manual/ > > I see open-source norms as requiring: > - documentation should be part of packages so it's available without > the net > - built docs are binaries and anyone must be able to build docs from > the doc sources > - all of this should be encapsulated in a build procedure that does > not require manual steps > > > Users I suspect don't care about building docs if they are building > > for themselves and frankly our build chain especially now that we have > > translations Is very complicated and has always been complicated > > (perhaps a bit more so with the introduction of our (lets make sure > > our docs reflect our changes in the branch) which is why we have this > > new fangled visual examples build that actually tests our doc examples > > to generate the images. I wouldn't want any packager to waste time > > trying to get all the glue to make that work unless they have a > > pressing requirement to do so. > > It's best just downloaded and installed. > > That sounds like "this is open source in name only; just use our docker > container"! As mentioned in my other email. https://gitea.osgeo.org/postgis/postgis/src/branch/master/doc/html/images/Makefile.in#L56 There are 3 options that all serve the same purpose, so you just need one of these: rsvg-convert we added cause it seemed like a simpler option for many than having a full graphmagick imagemagick installed But your options are rsvg-convert gm convert, and old imagick convert Though I am thinking now there is still a benefit in building html docs without images (for developers) so maybe we shouldn't just turn it off but just mention it lacks images. Though that wouldn't be useful for packages though. I agree we should check if rsvg-convert is available as part of configure check or any of the others and just disable docs building if none of those is available. Point taken that anyone should be able to build everything. Yes I hate the "Just use docker" mantra too. Anyway I guess we'll need another RC to sort this out, or do people feel we should just address these in a 3.7.1 release? I especially want to hear from packagers. Given it seems most packagers have given up building docs before 3.7, I don't see a harm in just pushing this issue to 3.7.1. I suspect a 3.7.1 will be coming in a month or two given the flood of security patches/complaints we?ve seen in our security team for all our branches. Just because of automated AI security runs of the world. Thanks, Regina From lr at pcorp.us Wed Sep 9 08:39:23 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 11:39:23 -0400 Subject: PostGIS Day 2026 Call for Presentations is open Message-ID: <00a601dd4071$63c28f00$2b47ad00$@pcorp.us> PostGIS Day 2026 will be November 19. Call for talk ideas is open now. Registration is free! This is a virtual community conference all about PostGIS geospatial. Details: https://www.snowflake.com/en/postgis-day/ CFP: https://talks.osgeo.org/postgis-day-2026/cfp Hope to see you all there, Regina