[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