On 2013-06-01 05:18, Christoph Berg wrote:
> Re: Andreas Beckmann 2013-05-31 <51a8feac.5090...@debian.org>
>> I can reproduce this manually with pbuilder in the minimal chroot
>> created by piuparts. But not in my regular pbuilder chroot. (postgresql
>> is running there if permitted by policy-rc.d).
>
> Btw, can you share this policy-rc.d?
#!/bin/sh
test "$1" = "mysql" && exit 0
test "$1" = "postgresql" && exit 0
exit 101
>> I can "fix" this in the piuparts chroot if I install devscripts first
>> and postgresql afterwards - now the daemon is running.
Narrowing this down to installing perl ... which reminded me of your
first reply:
On 2013-05-30 06:00, Christoph Berg wrote:
> I touched the "create cluster" part a bit, but I don't think that's
> your problem:
>
> diff -pu ../wheezy/debian/maintscripts-functions
debian/maintscripts-functions
> --- ../wheezy/debian/maintscripts-functions 2012-10-15
07:00:27.000000000 -0700
> +++ debian/maintscripts-functions 2013-05-10 18:52:30.000000000 -0700
> [...]
> @@ -29,7 +32,10 @@ configure_version() {
> [ "$VERSION" ] || { echo "Error: configure_version: need version
parameter" >&2; exit 1; }
> if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
> [ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf
2>/dev/null)" ]; then
> - [ "$2" ] || /usr/bin/pg_createcluster -u postgres $VERSION
main || {
> + # skip creating the main cluster when this is not the first
install, or
> + # when explicitely disabled ($create is 1/0/"")
> + create=$(perl -I/usr/share/postgresql-common -mPgCommon -e
'print PgCommon::config_bool(PgCommon::get_conf_value 0, 0,
"createcluster.conf", "create_main_cluster")')
> + [ "$2" ] || [ "$create" = "0" ] || /usr/bin/pg_createcluster
-u postgres $VERSION main || {
> echo "Error: could not create default cluster. Please create it
manually with
>
> pg_createcluster $VERSION main --start
Do you need anything from perl that is not provided by perl-base?
> I'd bet this is a bug in the chroot, like no localhost interface, or
> failure to resolve "localhost". Or the 5432 is not available, but that
> should be a different error message.
I'm pretty sure the chroot is fine ...
> (Fwiw, I disagree with this bug being serious, as it apparently
> doesn't affect anyone but piuparts.)
... but your dependencies are insufficient.
Not that many people try to run postgresql in a minimal chroot :-)
>> PS: I noticed that pg uses ports 5433, 5434, ... if 5432 is not
>> available during installation - is there a way (preferrably via
>> preseeding) that forces it to use 5432 (as that is expected by many
>> other packages) and just fail if that is not available?
>
> For postgresql-common >= 142, you could try "port = 5432" in
> /etc/postgresql-common/createcluster.conf, that should work. Or just
> don't create a default cluster and use "pg_createcluster -p 5432".
>
> Why is that port unavailable there anyway? Shouldn't that be a clean
> testbed for the upgrade tests? (On the same ticket I don't really see
> the need for preseeding here, 5432 should not be used by anyone else
> at installation time.)
There are upgrade tests running in several independent chroots in
parallel - so ports become a shared ressource. Luckily not that many
tests need a database server, but there are usually some collisions that
need to be detected during the automated log file checking and the tests
will be rescheduled later on.
For mysql this is rather easy, because mysql-server installation will
just fail. postgresql continues with selecting a random port causing the
package to be tested later on to fail in strange ways (i.e. everybody
has a different way to say "cannot connect to database").
Since I'd like to only minimally interact with the postgresql
installation, preseeding would have been nice ...
As that is not an available option, I'll try to parse the port from the
config file ...
awk '/^port/ { print $3 }' /etc/postgresql/9.1/main/postgresql.conf
or can you give me a short perl expression that does this version-agnostic?
Of course this could also be solved by running the piuparts tests in
real virtualized environments instead of plain chroots ... patches
welcome :-)
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
