Processing commands for [EMAIL PROTECTED]:
severity 483350 serious
Bug#483350: pperl: FTBFS: pperl: perl script failed to start: No such file or
directory
Severity set to `serious' from `normal'
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
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:
Processing commands for [EMAIL PROTECTED]:
severity 483350 normal
Bug#483350: pperl: FTBFS: pperl: perl script failed to start: No such file or
directory
Severity set to `normal' from `serious'
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
severity 483350 normal
thanks
This is an artifact of the build environment. However, perhaps the name
of the script should be hashed by pperl, to shorten the name of the UNIX
domain socket.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
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
* 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
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:
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 ;
* 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
13 matches
Mail list logo
