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

Roger Leigh rleigh at codelibre.net
Thu Oct 28 21:46:40 UTC 2010


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?


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/20101028/fb2664e4/attachment-0002.pgp>


More information about the Buildd-tools-devel mailing list