pg.ddx.io postgis-users@lists.osgeo.org mailing list archive (PostGIS users)
help / color / mirror / Atom feedPostGIS 3.7.0rc2 released
12+ messages / 3 participants
[nested] [flat]
* PostGIS 3.7.0rc2 released
@ 2026-09-08 21:39 Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 13:24 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
0 siblings, 2 replies; 12+ messages in thread
From: Regina Obe @ 2026-09-08 21:39 UTC (permalink / raw)
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
@ 2026-09-09 00:14 ` Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:38 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
1 sibling, 2 replies; 12+ messages in thread
From: Greg Troxel @ 2026-09-09 00:14 UTC (permalink / raw)
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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
@ 2026-09-09 00:30 ` Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
1 sibling, 1 reply; 12+ messages in thread
From: Greg Troxel @ 2026-09-09 00:30 UTC (permalink / raw)
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.)
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
@ 2026-09-09 01:00 ` Regina Obe <lr@pcorp.us>
2026-09-09 05:33 ` PostGIS 3.7.0rc2 released Sebastiaan Couwenberg <sebastic@xs4all.nl>
2026-09-09 12:39 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
0 siblings, 2 replies; 12+ messages in thread
From: Regina Obe @ 2026-09-09 01:00 UTC (permalink / raw)
> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
@ 2026-09-09 05:33 ` Sebastiaan Couwenberg <sebastic@xs4all.nl>
2026-09-09 15:15 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
1 sibling, 1 reply; 12+ messages in thread
From: Sebastiaan Couwenberg @ 2026-09-09 05:33 UTC (permalink / raw)
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 05:33 ` PostGIS 3.7.0rc2 released Sebastiaan Couwenberg <sebastic@xs4all.nl>
@ 2026-09-09 15:15 ` Regina Obe <lr@pcorp.us>
0 siblings, 0 replies; 12+ messages in thread
From: Regina Obe @ 2026-09-09 15:15 UTC (permalink / raw)
> From: Sebastiaan Couwenberg via postgis-users <postgis-
> 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
@ 2026-09-09 12:39 ` Greg Troxel <gdt@lexort.com>
2026-09-09 15:30 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
1 sibling, 1 reply; 12+ messages in thread
From: Greg Troxel @ 2026-09-09 12:39 UTC (permalink / raw)
"Regina Obe" <lr at pcorp.us> 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"!
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 12:39 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
@ 2026-09-09 15:30 ` Regina Obe <lr@pcorp.us>
0 siblings, 0 replies; 12+ messages in thread
From: Regina Obe @ 2026-09-09 15:30 UTC (permalink / raw)
> From: Greg Troxel <gdt at lexort.com>
> Sent: Wednesday, September 9, 2026 8:40 AM
> To: Regina Obe <lr at pcorp.us>
> Cc: postgis-users at lists.osgeo.org; 'Darafei \"Kom?pa\" Praliaskouski'
> <me at komzpa.net>
> Subject: Re: PostGIS 3.7.0rc2 released
>
> "Regina Obe" <lr at pcorp.us> 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
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
@ 2026-09-09 01:38 ` Regina Obe <lr@pcorp.us>
2026-09-09 12:45 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
1 sibling, 1 reply; 12+ messages in thread
From: Regina Obe @ 2026-09-09 01:38 UTC (permalink / raw)
> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
2026-09-09 01:38 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
@ 2026-09-09 12:45 ` Greg Troxel <gdt@lexort.com>
0 siblings, 0 replies; 12+ messages in thread
From: Greg Troxel @ 2026-09-09 12:45 UTC (permalink / raw)
"Regina Obe" <lr at pcorp.us> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
@ 2026-09-09 13:24 ` Greg Troxel <gdt@lexort.com>
2026-09-09 14:53 ` PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
1 sibling, 1 reply; 12+ messages in thread
From: Greg Troxel @ 2026-09-09 13:24 UTC (permalink / raw)
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
^ permalink raw reply [nested|flat] 12+ messages in thread
* PostGIS 3.7.0rc2 released
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 13:24 ` PostGIS 3.7.0rc2 released Greg Troxel <gdt@lexort.com>
@ 2026-09-09 14:53 ` Regina Obe <lr@pcorp.us>
0 siblings, 0 replies; 12+ messages in thread
From: Regina Obe @ 2026-09-09 14:53 UTC (permalink / raw)
> 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.
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2026-09-09 15:30 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-08 21:39 PostGIS 3.7.0rc2 released Regina Obe <lr@pcorp.us>
2026-09-09 00:14 ` Greg Troxel <gdt@lexort.com>
2026-09-09 00:30 ` Greg Troxel <gdt@lexort.com>
2026-09-09 01:00 ` Regina Obe <lr@pcorp.us>
2026-09-09 05:33 ` Sebastiaan Couwenberg <sebastic@xs4all.nl>
2026-09-09 15:15 ` Regina Obe <lr@pcorp.us>
2026-09-09 12:39 ` Greg Troxel <gdt@lexort.com>
2026-09-09 15:30 ` Regina Obe <lr@pcorp.us>
2026-09-09 01:38 ` Regina Obe <lr@pcorp.us>
2026-09-09 12:45 ` Greg Troxel <gdt@lexort.com>
2026-09-09 13:24 ` Greg Troxel <gdt@lexort.com>
2026-09-09 14:53 ` Regina Obe <lr@pcorp.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox