Re: Postgresql issue on Debian's autobuilder network
Am Dienstag, den 06.03.2012, 21:19 +0100 schrieb Kurt Roeckx:
> On Wed, Feb 29, 2012 at 10:36:18AM +0100, bojo42 wrote:
> > Oops sorry, i hadn't finished the mail yet. Please read on below ...
> >
> > Am Mittwoch, den 29.02.2012, 10:27 +0100 schrieb bojo42:
> > > Hi guys,
> > >
> > > in the course of updating the pspp package in Debian we ran in an issue
> > > that seems a bit special to Debian's autobuilders. Meaning upstream's
> > > testsuite fails because it can get a connection to the postgresql
> > > server:
> > >
> > >
> > > waiting for server to start......LOG: could not translate service
> > > "/build/buildd-pspp_0.7.9+git20120219-1-amd64-O7Y1R3/pspp-0.7.9
> > > +git20120219/tests/testsuite.dir/184/.s.PGSQL.6543" to address:
> > > Non-recoverable failure in name resolution
> > > WARNING: could not create Unix-domain socket
> > > FATAL: no socket created for listening
> > >
> > > After comparing it to my local and successful builds with pbuilder and
> > > current sid we think it is due to the long path for the Unix domain
> > > socket. One of the upstream author (who also is a DD) hinted that he
> > > had such an error with autobuilder and another of his projects. They
> > > also had a patch to workaround the limit for Unix domain sockets:
> > >
> >
> > http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=6e170b4c7802f4f388ec63d4c1146de830d98669
> >
> > Now i like to ask you what we can do about the issue, for my package we
> > already have Bug#660854 assigned to this build failure.
>
> So can you use the same solution in your package?
Unfortunatly no, as such a patch would be needed in Postgres.
> I also wonder if it's possible to use a relative filename instead.
That was my first tought as well, but after discussion with upstream it
does not seem possible.
>
> If you expect us to do something about this on the buildd side,
> we'd have to modify sbuild to create a different path.
A shorter build path would definitely solve the problem. To workaround
the issue we now copy the SQL file to /tmp before calling it.
So best would probably be if this issue got solved in Postgres, second
that you shorten the package related infos in the build path on packages
that build depend on postgres, but that's more hackish.
>
>
> Kurt
>
Reply to: