[Pkg-postgresql-public] buildd path too long (postgresql-9.3 FTBFS)

[Roger Leigh]

On Sat, May 11, 2013 at 06:24:38PM -0700, Christoph Berg wrote:
> with the upload of postgresql-9.3 to experimental, we've enabled much
> more test suites in the package ("make check-world"). Unfortunately,
> this means that the package will fail on buildds because it cannot
> create the unix socket to connect to the temporary database cluster:
> 
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.3&arch=i386&ver=9.3~beta1-1&stamp=1368168716
> 
> connection to database failed: Unix-domain socket path "/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432" is too long (maximum 107 bytes)
> 
> This is an operating system limit (sizeof(struct sockaddr_un.sun_path),
> see unix(7)), not a limitation of PostgreSQL.
> 
> Given that only 107 bytes are available for use, I think it is
> excessive if the directory used by the buildds uses 77 of that (72%).
> 
> On the packaging side, we could easily replace "/build/" by "/b/", but
> that saves only 4 bytes, while we'd need to save at least 11. Changing
> the location to be somewhere else seems like an invasive change to the
> upstream test system I'd rather like to avoid (pg_upgrade is a pretty
> sophisticated program that should rather operated as designed).
> 
> Would it be possible to use something shorter as the build directory?
> The second "buildd-" there seems to be redundant, and having the
> package name there only once would also save quite some space.

This issue has come up several times over the years.  We can shorten
the paths a bit, but that's really just papering over the problem;
a long version number or an NMU could push it back over the limit.
We need a solution that will work under all circumstances, not just
some of the time.

The main problem here is the assumption that it's safe to create a
socket inside the build tree; this is not the case.  I would suggest
that upstream either create the socket in /tmp or have a variable
like PG_BUILD_SOCKET_PATH which can be overridden to make it use
/tmp.  This would guarantee that the path limitation would never
be reached.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800