Hi,
Quoting "Kevin Grittner" <Kevin.Grittner@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
