[buildd-tools-devel] [Buildd-tools-devel] Bug#483350: pperl: FTBFS: pperl: perl script failed to start: No such file or directory

[Roger Leigh]

On Thu, Oct 28, 2010 at 10:46:40PM +0100, Roger Leigh wrote:
> On Sun, Jul 06, 2008 at 11:59:38PM +0200, Florian Weimer wrote:
> > * Roger Leigh:
> > 
> > > So, from what I understand of the report, pperl is creating a UNIX
> > > domain socket during its build, and the pathname is too long.
> > 
> > Correct.
> > 
> > > /build/user-pperl_0.25-5-amd64-0uuJx5/pperl-0.25-5/sockets/pperlnPLXc7
> > > /build/pperl-0.25-5/sockets/pperlnPLXc7
> > >
> > > That's 71 and 40 chars respectively (including NUL terminator if
> > > needed).  I don't see either as being excessively long.  Is this really
> > > what caused the failure, or is something else going on here?  We're
> > > nowhere near exceeding UNIX_PATH_MAX.
> > 
> > pperl uses an escaped form of the script name (which again resides in
> > the build directory) as the file name component of the socket, crossing
> > over the 109 character limit as a result.  As I wrote in the bug report,
> > I think this is an issue with pperl which should be fixed.  However,
> > with 70sh characters in the path and a base16 encoding of a 128-bit
> > hash, this still leaves us very close to the limit.
> 
> Looks like this is still an unresolved problem 30 months on:
> 
> Can't create listen socket: Address already in use at /build/rleigh-pperl_0.25-5-amd64-IXs0Ue/pperl-0.25/sockets/pperl1gs2Ym line 275
> p
> 
> Did you have any luck getting upstream to fix this?  I saw that
> #533934 exists, but it doesn't have any further details.
> 
> I think that on the sbuild side, there's not much I can really fix:
> it's a path length restriction that's completely out of our hands,
> so we can mitigate the effects, but we can never guarantee
> reliability.
> 
> I think the only sane approach here for upstream is to create the
> sockets in /tmp.  You can legitimately create such temporary files in
> TMPDIR, perhaps even in a temporary directory created using
> tmpnam or one of its equivalents for creating temporary directories.
> This would *ensure* the length limits wouldn't be exceeded.
> And on the debian side, you can set TMPDIR when you run make if
> that's needed.
> 
> Again on the upstream side, I think some awareness of the problem
> would be useful.  The build scripts and/or the test programs could
> check if the maximum length was exceeded and fail with an appripriate
> error.
> 
> 
> Would there be any objection to closing the sbuild bug?

Closing this bug.  It's not a bug in sbuild or something we can
work around in sbuild with any degree of reliability.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20101108/3e30ff74/attachment-0001.pgp>