Test: postgis (but slony and psqlodbc have the exact same error)
1. installing dependencies (works as in the autopkgtest)
2. check pg_buildext supported-versions
=> 10
ok that works and is as expected
3. + pg_virtualenv -v 10 sh -e
/usr/bin/pg_virtualenv: line 174: /tmp/pgpassword.gJU4VI: Permission denied
So the virtualenv call has the issue as it was expected from the permission error already.
^^ This happens as-is without anything from my PPAs or proposed.
This file is generated like:
PWFILE=$(mktemp -t pgpassword.XXXXXX)
chown postgres:postgres "$PWFILE"
And at the time of the error it is like:
-rw------- 1 postgres postgres 0 May 31 13:35 /tmp/pgpassword.fCpFSb
The permissions set by mktemp in src:coreutils are 0600 (file) and 0700 (dir) for ages.
And there as no change to the package in bionic since 18 Jan 2018.
I've also ran the slony and psqlodbc tests - both worked fine.
So we can release these builds but need to consider backporting the password fix.
=> that will be covered via an MP to the test hints
Manual checks on armhf in canonistack
Test: postgis (but slony and psqlodbc have the exact same error) pg_virtualenv: line 174: /tmp/pgpassword .gJU4VI: Permission denied
1. installing dependencies (works as in the autopkgtest)
2. check pg_buildext supported-versions
=> 10
ok that works and is as expected
3. + pg_virtualenv -v 10 sh -e
/usr/bin/
So the virtualenv call has the issue as it was expected from the permission error already.
^^ This happens as-is without anything from my PPAs or proposed.
This file is generated like: .fCpFSb
PWFILE=$(mktemp -t pgpassword.XXXXXX)
chown postgres:postgres "$PWFILE"
And at the time of the error it is like:
-rw------- 1 postgres postgres 0 May 31 13:35 /tmp/pgpassword
Since the test runs as root that access fails. /salsa. debian. org/postgresql/ postgresql- common/ -/commit/ aa4829c899a3cf7 ea6c90990d989dd 57d2a63857
This isn't a problem with the new postgresql that we have prepared.
This was later made more resilent in https:/
As soon as that permission issue is fixed (in the manual test) then it runs fine.
All that seems to make sense, the one puzzling part that remains why has this ever worked https:/ /autopkgtest. ubuntu. com/packages/ p/postgis/ bionic/ armhf ?
The permissions set by mktemp in src:coreutils are 0600 (file) and 0700 (dir) for ages.
And there as no change to the package in bionic since 18 Jan 2018.
I've also ran the slony and psqlodbc tests - both worked fine.
So we can release these builds but need to consider backporting the password fix.
=> that will be covered via an MP to the test hints