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

Roger Leigh rleigh at whinlatter.ukfsn.org
Sun Jul 6 21:50:50 UTC 2008


On Sun, Jul 06, 2008 at 10:47:10PM +0200, Lucas Nussbaum wrote:
> On 05/07/08 at 20:05 +0200, Florian Weimer wrote:
> > * Lucas Nussbaum:
> > 
> > >> If you insist on using this particular buildd configuration (which is
> > >> not matched by any official buildd, AFAICT), please take this issue to
> > >> the technical committee, or make it explicit in Policy.
> > >
> > > This buildd configuration is used by the sbuild package.
> > 
> > The official buildds only embed the package name once, and do not
> > include the Debian version and the architecture, saving roughly 45
> > characters.
> > 
> > >> Of course, I could use a temporary directory outside the build tree, but
> > >> if I honour TMPDIR, someone could still play similar games with me, so I
> > >> don't see the point of doing that.
> > >
> > > At least it would work by default...
> > 
> > It seems to work with sbuild by default, too...
> 
> it works with the buildd's sbuild, not with the packaged sbuild.
> 
> i'm reassigning this to the sbuild package, let's see what the sbuild
> maintainer thinks.

So, from what I understand of the report, pperl is creating a UNIX
domain socket during its build, and the pathname is too long.

While the packaged sbuild does embed more information into the build
directory path (user-package_version-arch-XXXXXX), we could shorten it.
However, this isn't fixing the root cause of the problem, just papering
over it--it could still be triggered by a long package name and version,
for instance.  The fact that the buildd sbuild uses a shorter path
doesn't mean a longer path is broken, IMO.

We could shorten the path in the packaged sbuild; the change is a
1-liner.  However, it was added so that it would be possible to build
different versions of the same package on multiple architectures
simultaneously in the same build location (people are doing that).
We previously put some of that information in a directory tree i.e.
/build/user/package-.... but this doesn't save you any path length
space, and is harder to visualise when cleaning up.
If possible, I'd prefer an alternative solution.

/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.

I'll try a test build on my system to see if it works with my sbuild
setup.


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.





More information about the Buildd-tools-devel mailing list