On Thu, Oct 13, 2005 at 03:38:17PM +0200, Bastian Blank wrote: >On Thu, Oct 13, 2005 at 11:28:56PM +1000, Brendan O'Dea wrote: >> Yeah, although in practice it works 99% of the time. > >It breaks on a z990, which is nothing like a slow machine.
Speed has nothing to do with it. As you've pointed out, it's a race. This particular test has never failed for me on my sad old PII 450, on which I've built perl innumerable times. Which is not to say that it won't the very next time I try. The granularity of the time measurement is the problem. If the alarm comes in a fraction of a second past 1s, *and* the alarm was set a hair less than that iterval before the second ticked over, then the test will fail. >> 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. > >It is a problem to hide bugs, so I disagree with this. I don't believe that this is a bug (or a problem, to use the language of the Social Contract) at this point. If this occurs *regularly* when building perl on s390 then it certainly is a bug, either with perl or with s390, either way it should be fixed. If, on the other hand this is a 1/100 failure which impacts only the occaisional build, then I don't belive that it's a problem, merely a side-effect of testing which is otherwise beneficial to the end user of binary packages. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
