Geoff - is it possible that this problem might be caused by time skew
between NFS servers? Are any parts of the build, or files accessed by
it, on NFS?
Cheers,
Simon
On 24/06/13 23:44, Geoffrey Mainland wrote:
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only claim was that I
No, it's all done on a local (ZFS) file system (I don't even have any
NFS volumes mounted), although I *am* using a separate build tree.
Geoff
On 06/28/2013 10:30 AM, Simon Marlow wrote:
Geoff - is it possible that this problem might be caused by time skew
between NFS servers? Are any parts
This makes me sad. You should shout when performance tests fail.
Even if they sometimes fail and sometimes not?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Surprisingly (?), no T149 or process007.
Yes, you do have these tests failing:
Unexpected passes:
perf/should_run T149 (normal)
Unexpected failures:
../../libraries/process/tests process007 [bad stdout] (normal)
I learned not to worry about performance tests - they seem to be quite
I just ran validation (once without any parameters and once with --normal) and
got no failures,
except for some tests that always fail. Looks like the problem may be solved.
Janek
Dnia wtorek, 25 czerwca 2013, Geoffrey Mainland napisał:
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only
Great, thanks for checking!
On 06/25/2013 03:43 PM, Jan Stolarek wrote:
I just ran validation (once without any parameters and once with --normal)
and got no failures,
except for some tests that always fail. Looks like the problem may be solved.
Janek
Dnia wtorek, 25 czerwca 2013,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/06/13 15:43, Jan Stolarek wrote:
I just ran validation (once without any parameters and once with
--normal) and got no failures, except for some tests that always
fail. Looks like the problem may be solved.
Janek
Dnia wtorek, 25 czerwca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/06/13 21:06, Jan Stolarek wrote:
T149 has been failing for a very long time (a few weeks at least).
I also had process007 fail.
Janek
Dnia wtorek, 25 czerwca 2013, Mateusz Kowalczyk napisał:
On 25/06/13 15:43, Jan Stolarek wrote:
I
] On
| Behalf Of Jan Stolarek
| Sent: 25 June 2013 21:06
| To: ghc-devs@haskell.org
| Subject: Re: Unreliability of the build system
|
| T149 has been failing for a very long time (a few weeks at least). I also had
| process007 fail.
|
| Janek
|
| Dnia wtorek, 25 czerwca 2013, Mateusz
I get the errors when running the testsuite too, but I excerpted the
earliest recache warning from my full validation run. The same tests
consistently fail for me.
I only get the errors when running the testsuite with BINDIST=YES, as
expected.
Geoff
On 06/24/2013 12:49 PM, Jan Stolarek wrote:
The same tests consistently fail for me.
Even if you run them separately with 'make TEST=failingTest'?
I only get the errors when running the testsuite with BINDIST=YES, as
expected.
I'm running validation without BINDIST=YES at the moment, will run the second
validation later.
Where do you
I thought it was obvious that I only meant that it was reliable for me :)
Reliable for me is a bit of oxymoron in the context of validating correctness
of software :) I
guess that's why I titled this thread Unreliability of the build system.
I'm running ext4.
Is there any method by which you
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only claim was that I have a set of steps that can reliably reproduce
an error on my system, not that these steps will reliably reproduce it
on an arbitrary system, e.g., yours. Still, being able to reliably
reproduce an error, even if only on one
The testsuite does check whether the package.cache timestamp changed
while running a test. If it did then you'll get a
Package cache timestamps do not match: [...]
framework failure. Do you know whether that happened?
If it checks cache local to the build tree, then I have no idea. I just
On Fri, May 17, 2013 at 8:52 AM, Ian Lynagh i...@well-typed.com wrote:
On Wed, May 15, 2013 at 12:25:14PM -0700, David Terei wrote:
I'd point out though that GHC's 'no validate failures' is very
frequently violated which did confuse me a lot when getting started.
This is at least partly
On Fri, May 17, 2013 at 3:14 PM, Ian Lynagh i...@well-typed.com wrote:
On Fri, May 17, 2013 at 11:34:01AM -0500, Gabriel Dos Reis wrote:
Can't the build bots instructed to systematically fire up on every
commit for testing on the various platforms you currently do?
In principle, yes,
I use separate build dirs because I synchronize my tree across multiple
machines. It also makes it easy to blow away the build.
Jan, you clearly have some stale build artifacts. Don't mix in-tree and
out-of-tree builds. If you want to use out-of-tree builds, you can
eliminate leftover build
Don't mix in-tree and out-of-tree builds.
I *think* I am not mixing them. I'm running builds either in ghc-build (lndired
to ghc-working,
this often gets blown away) and ghc-validate (these are in-tree builds, cleaned
with
maintainer-clean). There are no builds in ghc-working.
If you want
18 matches
Mail list logo
