Your message dated Thu, 13 Oct 2005 23:28:56 +1000
with message-id <[EMAIL PROTECTED]>
and subject line Bug#333702: perl - t/op/alarm.t is racy
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 13 Oct 2005 10:31:25 +0000
>From [EMAIL PROTECTED] Thu Oct 13 03:31:25 2005
Return-path: <[EMAIL PROTECTED]>
Received: from mobilewave.waldi.eu.org [82.139.201.22]
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EQ0Mv-0007j9-00; Thu, 13 Oct 2005 03:31:25 -0700
Received: by mobilewave.waldi.eu.org (Postfix, from userid 1000)
id 2B779184D2; Thu, 13 Oct 2005 12:30:29 +0200 (CEST)
Date: Thu, 13 Oct 2005 12:30:28 +0200
From: Bastian Blank <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: perl - t/op/alarm.t is racy
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.11
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Package: perl
Version: 5.8.7-6
Severity: important
There was an error while trying to autobuild your package:
> Automatic build of perl_5.8.7-6 on debian-31 by sbuild/s390 69
[...]
> t/op/alarm................................# Failed at op/alarm.t line 50
> FAILED at test 4
[...]
> Failed 1 test script out of 914, 99.89% okay.
This test checks if the real time differs not much than one second from
the expected. It is not guaranteed, that the process gets a timeslice
within this time.
Bastian
---------------------------------------
Received: (at 333702-close) by bugs.debian.org; 13 Oct 2005 13:29:01 +0000
>From [EMAIL PROTECTED] Thu Oct 13 06:29:01 2005
Return-path: <[EMAIL PROTECTED]>
Received: from londo.c47.org [198.142.1.20] (mail)
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EQ38n-0007VF-00; Thu, 13 Oct 2005 06:29:01 -0700
Received: from bod by londo.c47.org with local (Exim 3.36 #1 (Debian))
id 1EQ38i-0008CG-00; Thu, 13 Oct 2005 23:28:56 +1000
Date: Thu, 13 Oct 2005 23:28:56 +1000
From: Brendan O'Dea <[EMAIL PROTECTED]>
To: Bastian Blank <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#333702: perl - t/op/alarm.t is racy
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.9i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
On Thu, Oct 13, 2005 at 12:30:28PM +0200, Bastian Blank wrote:
This test checks if the real time differs not much than one second from
>the expected. It is not guaranteed, that the process gets a timeslice
>within this time.
Yeah, although in practice it works 99% of the time.
The perl build runs a bunch of tests, some of which are occasionally
give false positives on the buildds.
While this can be annoying on m68k and some of the slower architectures,
the tests more often than not show up problems with the build-chain or
kernel.
Problems with gcc exhibited on arm were what prompted this upload in the
first place (so don't bother rebuilding this version, the fix didn't
work... I'm hoping to get access to an arm machine to investigate
further and there will be another upload shortly).
This test in question *is* racy, unfortunately it's difficult to get a
finer timing granularity without going to Time::HiRes, which is not
tested at that point which introduces an alternate failure case.
For the moment I'm closing this bug, acknowledging that it's a potential
problem, but one that occurs rarely enough (in my experience) not to be
a real problem.
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
