[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#462226: coreutils: FTBFS on mips: tests failed: rm/deep-1, rm/dangling-symlink, ...



Michael Stone wrote:
> On Wed, Jan 23, 2008 at 01:15:29PM +0100, you wrote:
>> On 23/01/08 at 11:06 +0100, Lucas Nussbaum wrote:
>>> Package: coreutils
>>> Version: 6.10-1
>>> Severity: serious
>>>
>>> Hi,
>>>
>>> coreutils 6.10-1 failed to build on mips:
>>>
>>> > Making check in rm
>>> > make[3]: Entering directory `/build/buildd/coreutils-6.10/build-tree/coreutils-6.10/tests/rm'
>>> > /usr/bin/make  check-TESTS
>>> > make[4]: Entering directory `/build/buildd/coreutils-6.10/build-tree/coreutils-6.10/tests/rm'
>>> > make[5]: Entering directory `/build/buildd/coreutils-6.10/build-tree/coreutils-6.10/tests/rm'
>>> > FAIL: deep-1.log
>
> This makes me think we've got a cross compiler or somesuch that can't run the
> executables we just built. (This is the very first test, and would fail if the
> generated "mktemp" wouldn't execute, for example.) Although configure didn't
> think it was cross compiling. Can we get an actual fail log from the buildd?
>
>> I can't reproduce that failure on casals.d.o. However, the build on
>> casals fails later:
>>
>>> Making check in touch
>>> make[3]: Entering directory
>>> `/home/lucas/cuu/coreutils-6.10/build-tree/coreutils-6.10/tests/touch'
>>> /usr/bin/make  check-TESTS
>>> make[4]: Entering directory
>>> `/home/lucas/cuu/coreutils-6.10/build-tree/coreutils-6.10/tests/touch'
>>> make[5]: Entering directory
>>> `/home/lucas/cuu/coreutils-6.10/build-tree/coreutils-6.10/tests/touch'
>>> SKIP: now-owned-by-other.log
>>> PASS: read-only.log
>>> PASS: relative.log
>>> PASS: not-owner.log
>>> FAIL: no-create-missing.log
>
> This seems to be actual brokenness on the system. Cf.:
> sh-3.1$ ./touch -c - >&-
> ./touch: setting times of `-': Unknown error 4294967207

ruby1.9 is another package affected by this.

> Kinda looks like the errno.h doesn't match the system or somesuch.

I did a test-build on mips/unstable with an upstream 2.6.24-rcX kernel
and it built fine. I believe the problems are caused by a set of kernel
bugs which were fixed in the 2.6.20 - 2.6.22 series. The buildd kernels
(2.6.16) also show severe performance degradation, which led to a
backlog of pending package builds.

I'm currently validating the stability of 2.6.24 on the same hardware
as our buildds have, I hope the problem can be solved over this weekend.


Thiemo


Reply to: