Comment 4 for bug 1928773

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Manual checks on armhf in canonistack

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

Since the test runs as root that access fails.
This isn't a problem with the new postgresql that we have prepared.
This was later made more resilent in https://salsa.debian.org/postgresql/postgresql-common/-/commit/aa4829c899a3cf7ea6c90990d989dd57d2a63857

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