Opened 5 years ago
Closed 5 years ago
#4515 closed defect (fixed)
00-regress-install doesn't get created legacy regress fails
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.0.0 |
Component: | build | Version: | master |
Keywords: | Cc: |
Description
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
Change History (13)
comment:1 by , 5 years ago
Version: | 2.5.x → trunk |
---|
comment:2 by , 5 years ago
Summary: | 00-regress-install doesn't get created → 00-regress-install doesn't get created legacy regress fails |
---|
comment:3 by , 5 years ago
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.
comment:5 by , 5 years ago
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 ) {
comment:6 by , 5 years ago
Priority: | medium → blocker |
---|
comment:7 by , 5 years ago
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)
comment:8 by , 5 years ago
As noted by Myon on IRC - started at this commit
https://git.osgeo.org/gitea/postgis/postgis/commit/e59438ed49
comment:9 by , 5 years ago
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.
comment:10 by , 5 years ago
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.
comment:11 by , 5 years ago
Priority: | blocker → medium |
---|
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.
comment:13 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
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.