[nightly] 05-Oct-2008 build of HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com)

Build description = HEAD on i386-unknown-linux (cam-02-unx.europe.corp.microsoft.com) Build location= /playpen/simonmar/nightly/HEAD Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Sun Oct 5 18:02:05 BST 2008. checking out

[nightly] 05-Oct-2008 build of HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com)

Build description = HEAD on x86_64-unknown-linux (cam-04-unx.europe.corp.microsoft.com) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Sun Oct 5 19:00:01 BST 2008. ***

patch applied (ghc-6.10/ghc): Fix generating OS X installers: Set COMMAND_MODE=unix2003

Sun Oct 5 15:27:15 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Fix generating OS X installers: Set COMMAND_MODE=unix2003 If we don't specify COMMAND_MODE=unix2003 then xcodebuild defaults to setting it to legacy, which means that ar builds archives without a table of contents. That makes th

patch applied (ghc): Fix generating OS X installers: Set COMMAND_MODE=unix2003

Sun Oct 5 15:27:15 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * Fix generating OS X installers: Set COMMAND_MODE=unix2003 If we don't specify COMMAND_MODE=unix2003 then xcodebuild defaults to setting it to legacy, which means that ar builds archives without a table of contents. That makes th

Re: base 3 + base 4 compatibility?

On Sun, 2008-10-05 at 15:11 +0100, Claus Reinke wrote: > Is it really always safe to combine packages that depend on one base > with packages that depend on another? My guess is "no, but ghc will > catch any compatibility issues", so the cabal warning perhaps shouldn't > be dropped? As far as I

Re: [EMAIL PROTECTED]: Nasty (but fixed) complexity-changing bug thingy in bytestring]

On Sun, 2008-10-05 at 14:14 +0100, Ian Lynagh wrote: > On Sat, Oct 04, 2008 at 04:00:57PM -0700, Duncan Coutts wrote: > > On Sat, 2008-10-04 at 15:50 -0700, Don Stewart wrote: > > > BTW, this is why we cannot ship with the old bytestring fork of 0.9 > > > bumping around in GHC. > > > > That and th

Re: [EMAIL PROTECTED]: Nasty (but fixed) complexity-changing bug thingy in bytestring]

igloo: > On Sat, Oct 04, 2008 at 04:00:57PM -0700, Duncan Coutts wrote: > > On Sat, 2008-10-04 at 15:50 -0700, Don Stewart wrote: > > > BTW, this is why we cannot ship with the old bytestring fork of 0.9 > > > bumping around in GHC. > > > > That and the not-closing-file-handles bug. > > I believe

Re: assertion fail

Simon, I'm getting ASSERT failures for these two: Simple16(normal) T2627b(normal) Both line 286 of TcTyFuns. Hmmm, that's TcSimplify.tcSimplifyRestricted's fault. It calls reduceContext twice with the same set of wanteds. If a wanted equality gets solved the first time around, the

patch applied (ghc-6.10/ghc): We need to set datadir = $(libdir) in bindists

Sun Oct 5 07:33:07 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * We need to set datadir = $(libdir) in bindists We already do in the normal Makefiles. This is because GHC needs package.conf and unlit to be in the same place (and things like ghc-pkg need to agree on where package.conf is, s

patch applied (ghc): We need to set datadir = $(libdir) in bindists

Sun Oct 5 07:33:07 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]> * We need to set datadir = $(libdir) in bindists We already do in the normal Makefiles. This is because GHC needs package.conf and unlit to be in the same place (and things like ghc-pkg need to agree on where package.conf is, s

mailing list settings for cc?

Sometimes, when I cc emails to those who might be particularly interested, or able to do something about the issues discussed, I notice that the email arrives in the list without the cc. Example: the email with the subject "base 3 + base 4 compatibility?" was cc-ed to 3 addresses, but arrived in

base 3 + base 4 compatibility?

Is it really always safe to combine packages that depend on one base with packages that depend on another? My guess is "no, but ghc will catch any compatibility issues", so the cabal warning perhaps shouldn't be dropped? Either way, safe does not mean useable, eg, how does one use such combinat

Re: Validation error

On Fri, Oct 03, 2008 at 06:13:02PM +0100, Simon Peyton-Jones wrote: > sorry. I had -Werror switched off because I was compiling extralibs too, > which aren't warning free. I don't know if I can say "-Werror for all except > extralibs" can I? No, currently we build the extralibs and bootlibs in

Re: [EMAIL PROTECTED]: Nasty (but fixed) complexity-changing bug thingy in bytestring]

On Sat, Oct 04, 2008 at 04:00:57PM -0700, Duncan Coutts wrote: > On Sat, 2008-10-04 at 15:50 -0700, Don Stewart wrote: > > BTW, this is why we cannot ship with the old bytestring fork of 0.9 > > bumping around in GHC. > > That and the not-closing-file-handles bug. I believe I've just fixed this,

Re: patch to drop Win32 dep on bytestring

On Sun, Oct 05, 2008 at 12:35:36AM +0100, Thomas Schilling wrote: > 2008/10/4 Duncan Coutts <[EMAIL PROTECTED]>: > > all people who use the ghc-6.10 branch darcs > > repos deleting their libraries/bytestring repo and getting the new one. > > How is that different from having to call ./darcs-all ge

Daily report for stable

Build results: tnaur x86 Linux stable: pass x86 Windows stable: pass x86 Windows stable fast: pass pass lost pass fail (failed stage1) pass fail (failed stage1) x86-64 Linux stable: lost Dropping unexpected test passes reports from builders not seen in 7 days: gabor stable x86-

Daily report for head

Build results: x86-64 Linux head:lost x86 Windows head: pass x86 Windows head fast:pass pass lost pass pass pass gabor head: lost kgardas head: pass malcolm head: pass mnemosyne x86-64 Gentoo head: fail (failed darcs)