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.
reassign 483350 sbuild 0.57.4-1
severity 483350 important
thanks
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
clone 483350 -1
reassign -1 pperl 0.25-5+b1
severity -1 normal
thanks
it works with the buildd's sbuild, not with the packaged sbuild.
Ah.
i'm reassigning this to the sbuild package, let's see what the sbuild
maintainer thinks.
As I said, it's a bug in pperl, too. During normal operation,
* 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
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
* 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
severity 483350 normal
thanks
I'm not sure if I should simply label your build environment as broken,
or if I need to move the sockets directory to some place with a shorter
path name.
I disagree with my build environment being broken:
severity 483350 serious
thanks
On 28/05/08 at 23:10 +0200, Florian Weimer wrote:
* Florian Weimer:
* Lucas Nussbaum:
Is it possible that the problem is caused by trying to resolve some
external domain name? Or connect to something on the internet?
It's related to the length of the
On 03/07/08 at 12:24 +0200, Florian Weimer wrote:
severity 483350 normal
thanks
I'm not sure if I should simply label your build environment as broken,
or if I need to move the sockets directory to some place with a shorter
path name.
I disagree with my build environment being
* Lucas Nussbaum:
Do you use Selinux?
Yes
Does the policy permit creation access of UNIX domain sockets in the
sockets subdirectory?
Does the kernel support Unix domain sockets?
Yes. The kernel is the etch amd64 kernel.
Okay, I tried that, too ...
This version has been auto-built on
On 28/05/08 at 22:07 +0200, Florian Weimer wrote:
* Lucas Nussbaum:
Do you use Selinux?
Yes
Does the policy permit creation access of UNIX domain sockets in the
sockets subdirectory?
Sorry, the answer was no, not yes.
Does the kernel support Unix domain sockets?
Yes. The
* Lucas Nussbaum:
Is it possible that the problem is caused by trying to resolve some
external domain name? Or connect to something on the internet?
It's related to the length of the name of the build directory. Somehow,
this reminds me of http://ars.userfriendly.org/cartoons/?id=20001014.
* Florian Weimer:
* Lucas Nussbaum:
Is it possible that the problem is caused by trying to resolve some
external domain name? Or connect to something on the internet?
It's related to the length of the name of the build directory. Somehow,
this reminds me of
Package: pperl
Version: 0.25-5
Severity: serious
User: [EMAIL PROTECTED]
Usertags: qa-ftbfs-20080527 qa-ftbfs
Justification: FTBFS on i386
Hi,
During a rebuild of all packages in sid, your package failed to build on
i386.
Relevant part:
make[1]: Entering directory
On 28/05/08 at 14:57 +0200, Florian Weimer wrote:
* Lucas Nussbaum:
This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3
is now the default on most architectures (even if it's not the case on
i386 yet). Consequently, many failures are caused by the switch to gcc
4.3.
* Lucas Nussbaum:
This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3
is now the default on most architectures (even if it's not the case on
i386 yet). Consequently, many failures are caused by the switch to gcc
4.3.
I don't see such a failure with GCC 4.3. What did you
* Lucas Nussbaum:
I don't see such a failure with GCC 4.3. What did you do to set up the
build chroot?
I didn't say that this bug was caused by gcc 4.3. It's just a
possibility.
The chroot is a minimal build chroot (debootstrap ; apt-get install
build-essential ; debfoster to remove all
On 28/05/08 at 15:22 +0200, Florian Weimer wrote:
* Lucas Nussbaum:
I don't see such a failure with GCC 4.3. What did you do to set up the
build chroot?
I didn't say that this bug was caused by gcc 4.3. It's just a
possibility.
The chroot is a minimal build chroot (debootstrap ;
18 matches
Mail list logo
