#1137426 postgresql-common: pg_virtualenv fails on some of the GNU/Hurd buildds

#1137426#5
Date:
2026-05-23 18:09:04 UTC
From:
To:
(This is probably not a bug in pg_virtualenv but some hiccup with the
hurd-* buildds but I thought it's a good idea to have this tracked in
the BTS anyway.)

The gnustep-sqlclient package uses pg_virtualenv in its
override_dh_auto_test target to test its Postgres backend.  This
worked very well on GNU/Hurd but started failing since some time on
some of the buildds (hurd-dbdd-tls-1 and ironforge), for example [1]:

LD_LIBRARY_PATH=/build/reproducible-path/gnustep-sqlclient-1.9.0/obj:$LD_LIBRARY_PATH \
  GNUSTEP_CONFIG_FILE=/build/reproducible-path/gnustep-sqlclient-1.9.0/test.conf LC_ALL=C.UTF-8 \
  pg_virtualenv -i "-U postgres -A trust" ./obj/testPostgres
Creating new PostgreSQL cluster 18/regress ...
install: cannot change owner and permissions of ‘/tmp/pg_virtualenv.1rGFCD/data/18/regress’: Operation not permitted
Error: could not create data directory; you might need to run this program with root privileges
make[1]: *** [debian/rules:39: override_dh_auto_test] Error 1

This leads to FTBFS and it cannot be given-back because the state is
quickly changed to "Failed".

Note that other packages using pg_virtualenv have the very same
problem, for instance pg-catcheck [2]:

for v in 18; do \
  pg_virtualenv -v $v debian/postgresql-$v-pg-catcheck/usr/lib/postgresql/$v/bin/pg_catcheck -v; \
done
Creating new PostgreSQL cluster 18/regress ...
install: cannot change owner and permissions of ‘/tmp/pg_virtualenv.udgTA9/data/18/regress’: Operation not permitted
Error: could not create data directory; you might need to run this program with root privileges

[1] https://buildd.debian.org/status/fetch.php?pkg=gnustep-sqlclient&arch=hurd-amd64&ver=1.9.0-7&stamp=1779532599&raw=0
[2] https://buildd.debian.org/status/fetch.php?pkg=pg-catcheck&arch=hurd-amd64&ver=1.6.0-2&stamp=1760034304&raw=0

#1137426#10
Date:
2026-05-27 17:10:45 UTC
From:
To:
Re: Yavor Doganov

Hi,

this was hitting all PG extension packages in unstable until earlier
this year, but then the problem disappeared.

gnustep-sqlclient from experimental still has the problem, so I guess
whatever it was, it still needs to be fixed in the experimental buildd
chroot.

Samuel, does that ring a bell?

Christoph

#1137426#15
Date:
2026-05-30 05:01:19 UTC
From:
To: