- Package:
- postgresql-common
- Source:
- postgresql-common
- Submitter:
- Yavor Doganov
- Date:
- 2026-05-30 05:03:02 UTC
- Severity:
- normal
(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
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
Yesterday it failed in unstable too, this time on mahler: https://buildd.debian.org/status/fetch.php?pkg=gnustep-sqlclient&arch=hurd-i386&ver=1.9.0-8&stamp=1780035340&raw=0