00-regress-install doesn't get created legacy regress fails

[robe]

I think this might be just an issue local to me as winnie doesn't seem to be having this issue and we should be configured the same way. Though I might override variables a little differently since my pathing is different

Issue is regress/00-regress-install folder doesn't get created anymore so I can only do make check with extensions.

Even with that I get legacy regress failure:

+psql:legacy.sql:11: error: \cd: could not change directory to "C:/ming64gcc81/projects/postgis/branches/3.0/regress/00-regress-install/share/contrib/postgis": No such file or directory

because it tries to cd into the non-existing folder

[robe]

I should add I also get this in the legacy regress failure which is kinda odd but perhaps related because it never was able to install legacy.sql

Why a non-existent file would produce too many open files seems a little strange.

+psql:legacy.sql:12: error: legacy.sql: Too many open files
 Starting up MapServer/Geoserver tests...
 Setting up the data table...
 public.wmstest.pt SRID:4326 TYPE:POLYGON DIMS:2
 Running Geoserver 2.0 NG tests...
 Geoserver1|POLYGON
 Geoserver2|4326
-Geoserver3|-500|AAAAAAMAAAABAAA
-Geoserver4|1
-Geoserver5|25|AAAAAAMAAAABAAA
-Geoserver6|25|AAAAAAMAAAABAAA
+ERROR:  function force_2d(geometry) does not exist at character 50
+ERROR:  function geomfromtext(unknown, integer) does not exist at character 69
+ERROR:  function force_2d(geometry) does not exist at character 50
+ERROR:  function force_2d(geometry) does not exist at character 50
 MapServer1|id
-MapServer2|-9465|AQcAAAABAAAAAQM|-9465
-MapServer2|-9460|AQcAAAABAAAAAQM|-9460
+ERROR:  function force_2d(geometry) does not exist at character 67
 MapServer3|id
-MapServer4|-9465|010700000001000|-9465
-MapServer4|-9460|010700000001000|-9460
+ERROR:  function force_2d(geometry) does not exist at character 67
 Removing the data table...
 Done.
-1869|POINT(1 2)
+ERROR:  function st_asbinary(unknown) is not unique at character 37
+psql:legacy.sql:54: error: uninstall_legacy.sql: No such file or directory
+Starting up MapServer/Geoserver tests...
+Setting up the data table...
+public.wmstest.pt SRID:4326 TYPE:POLYGON DIMS:2
+Running Geoserver 2.0 NG tests...
+Geoserver1|POLYGON
+Geoserver2|4326
+ERROR:  function force_2d(geometry) does not exist at character 50
+ERROR:  function geomfromtext(unknown, integer) does not exist at character 69
+ERROR:  function force_2d(geometry) does not exist at character 50
+ERROR:  function force_2d(geometry) does not exist at character 50
+MapServer1|id
+ERROR:  function force_2d(geometry) does not exist at character 67
+MapServer3|id
+ERROR:  function force_2d(geometry) does not exist at character 67
+Removing the data table...
+Done.

[robe]

This might actually be a real problem.

I just compiled and installed PostGIS 3.0.0alpha3, and legacy passed with my same script. Only difference is I'm installing from tarball instead of svn. I can't imagine that would be the issue though.

[pramsey]

Without instructions on how to reproduce I cannot offer an opinion.

[robe]

Myon has run into a similar issue, so I'm changing this to a blocker

From IRC 2019-10-06 logs

15:56:39	Myon:	anyone around who can explain how scriptdir() in regress/run_test.pl is supposed to work?
15:57:04	Myon:	that broke Debian's (hackish) way of running the regression tests on the installed packages
15:57:43	Myon:	things work at build time, but when the regression tests are told to run on the installed packages, they fail
15:57:49	Myon:	errors like https://pgdgbuild.dus.dg-i.net/view/Binaries/job/postgis-binaries/lastSuccessfulBuild/architecture=amd64,distribution=sid/consoleFull
15:57:50	sigq:	Title: postgis-binaries » amd64,sid amd64,sid Console [Jenkins] (at pgdgbuild.dus.dg-i.net)
15:58:17	Myon:	--- legacy_expected 2019-09-29 02:06:05.000000000 +0200
15:58:18	Myon:	+++ /tmp/pgis_reg/test_54_out 2019-10-06 17:43:51.178126685 +0200
15:58:18	Myon:	@@ -1,19 +1,8138 @@
15:58:18	Myon:	+\cd: could not change directory to "/tmp/autopkgtest.2sqTEN/tree/regress/00-regress-install/sha
15:58:20	Myon:	re/contrib/postgis": No such file or directory
15:59:05	Myon:	test runner is https://salsa.debian.org/debian-gis-team/postgis/blob/experimental/debian/tests/regress
15:59:06	sigq:	Title: debian/tests/regress · experimental · Debian GIS Project / postgis · GitLab (at salsa.debian.org)
16:00:29	robe2:	Myon that's interesting I get similar error too -- I thought it was just something on my local setup as bots aren't experiencing that - https://trac.osgeo.org/postgis/ticket/4515
16:00:30	sigq:	Title: #4515 (00-regress-install doesn't get created legacy regress fails) – PostGIS (at trac.osgeo.org)
16:01:02	Myon:	there is code to make it use the location from pg_config, but the glue around it is weird
16:01:19	Myon:	specifically I don't understand the idea of if ( $version and $version ne $libver ) {

[robe]

Regarding this issue, I discovered regress is being installed, but for some reason, it's installing in the root of my msys:

C:\ming64gcc81\msys\00-regress-install

instead of my source folder. The only thing I override is export PGIS_REG_TMPDIR, but winnie overrides that too and doesn't seem to suffer from same issue. The only other significant difference I can think of how we are configures is her source folder is on E: drive (separate drive from ming/msys environment)

[robe]

As noted by Myon on IRC - started at this commit

​https://git.osgeo.org/gitea/postgis/postgis/commit/e59438ed49

[strk]

The $version ne $libver conditional is to find script-based install of non-current version, which is needed when running with --upgrade-path "unpackagedX.Y--Z.Z"

The code tries to guess where non-extension scripts for version X.Y are found on the system.

[robe]

Okay I'm going to dismiss my issue as user error. After trying to compare what is different between my script and winnie's script, I tossed my script out and used hers and put back my different versions of things. Seem to work fine. No more errors. Have no clue what was wrong with my script before.

Also reverting to the 3.0.0beta1 did not help my issue evidentally started before then.

[robe]

I'm downgrading this from blocker to medium as its something we can't easily replicate and only happens with make installing in a less than common way.

[strk]

Please check if r17888 fixes this issue

[robe]

If Myon is happy I'm happy so closing this out. I tossed out my other script so can't check if it was the same issue as he had or not.