Hi, Quoting "Kevin Grittner" <kevin.gritt...@wicourts.gov>:
I haven't quite gotten it to work yet; I'll start over with 3.0 and see how it goes.
Let's stick to 2.x versions, first...
I'll also attach the results of the 2.6 attempt.
Thanks, that looks already pretty promising. ;-)
A few other issues in testing so far: (1) I see that a 'make dcheck' does a 'make install'. That's not right. For one thing I usually install in a location where I need to sudo to install; but more importantly, I want to do all checks *before* I install. It's easy enough to work around that for now, but I don't think it's acceptable long-term.
It does: "temp_install: creating temporary installation" means it's running make install in the background.
(2) After a 'make dcheck' failure, the cluster created for the testing is left running.
That counts as a bug. I also get that from time to time (and with Postgres-R testing on 3+ instances, it's even more annoying).
Note that the error just before that is, that a psql process it starts cannot connect to its postmaster ("startup of test test-conn-0A failed, skipping.") Please check the log (src/test/regress/dtester.log) for why that failed in the first place. Can you connect manually to the database (that's still running after a make dcheck)?
(3) If the install could check dependencies, report problems, and refuse to install without required packages, that would be less confusing for python novices (like me).
I'm not exactly a distutils hacker... Anybody else got any clue here?
Perhaps some of these problems will go away with python 3.0, but I figured I should pass the info along.
I'd rather suspect that more of them will arise. Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
