Re: Tracking intermittently failing CI jobs

Hello again, Thanks to everyone who pointed out spurious failures over the last few weeks. Here's the current state of affairs and some discussion on next steps. * * *Dashboard *** I made a dashboard for tracking spurious failures:

Tracking intermittently failing CI jobs

Hi all, I'd like to get some data on weird CI failures. Before clicking "retry" on a spurious failure, please paste the url for your job into the spreadsheet you'll find linked at https://gitlab.haskell.org/ghc/ghc/-/issues/21591. Sorry for the slight misdirection. I wanted the spreadsheet to

Re: Marge Bot repeatedly failing due to stat decreases

Thanks Ben! For future reference, is there anything that we as ordinary GHC developers can do to help Marge along when she gets stuck on stat changes? You mentioned that you amended a Marge batch to accept the changes before. Are there instructions on how to do this properly? For instance, which

Re: Marge Bot repeatedly failing due to stat decreases

Ryan Scott writes: > Something strange is still going on, since Marge now just opened an > empty merge batch [1]. > Indeed; it seems that she was confused by the fact that the merged MRs weren't yet closed. Fixed and restarted. Cheers, - Ben signature.asc Description: PGP signature

Re: Marge Bot repeatedly failing due to stat decreases

een receiving a flurry of e-mails all weekend about Marge Bot > > failing to validate a batch on CI. Moreover, the failures appear to be > > consistent each time. From the most recent one [1]: > > > Yesterday I had amended one of Marge's batches to accept the performance > ch

Re: Marge Bot repeatedly failing due to stat decreases

Ryan Scott writes: > Hello, > > I've been receiving a flurry of e-mails all weekend about Marge Bot > failing to validate a batch on CI. Moreover, the failures appear to be > consistent each time. From the most recent one [1]: > Yesterday I had amended one of Marge's

Marge Bot repeatedly failing due to stat decreases

Hello, I've been receiving a flurry of e-mails all weekend about Marge Bot failing to validate a batch on CI. Moreover, the failures appear to be consistent each time. From the most recent one [1]: Unexpected stat failures: /builds/ghc/ghc/tmp/ghctest-mel1y5lo/test spaces/testsuite

Re: validate-x86_64-darwin failing

We are in slow process of reprovisioning 1-2 new builders. One of our active builders had pretty bad hardware issues so for near term we’re down in mac builder capacity On Mon, Oct 14, 2019 at 8:41 AM Brandon Allbery wrote: > Apple makes that annoyingly difficult; someone has to in effect

Re: validate-x86_64-darwin failing

Apple makes that annoyingly difficult; someone has to in effect donate a Mac to the cause, preferably one with enough memory and fast CPU. (Not literally: one can keep the Mac physically, but would more or less lose use of it for any other purpose.) ___

Re: validate-x86_64-darwin failing

> On Oct 13, 2019, at 6:38 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Here's one: https://gitlab.haskell.org/rae/ghc/-/jobs/173464 >> I don't know if you >> can get more information... >> > Right, this particular job simply

Re: validate-x86_64-darwin failing

Richard Eisenberg writes: > Here's one: https://gitlab.haskell.org/rae/ghc/-/jobs/173464 > I don't know if you > can get more information... > Right, this particular job simply timed out (e.g. waited 10 hours) before a Darwin builder became

Re: validate-x86_64-darwin failing

gt;> validate-x86_64-darwin seems to be failing. I've restarted it when I >> came across the failure, but several small patches last night tripped >> on this. >> > Which jobs in particular failed? I looked through the recent job list > [1] but all Darwin jobs in the las

Re: validate-x86_64-darwin failing

Richard Eisenberg writes: > Hi devs, > > validate-x86_64-darwin seems to be failing. I've restarted it when I > came across the failure, but several small patches last night tripped > on this. > Which jobs in particular failed? I looked through the recent job list [1] b

validate-x86_64-darwin failing

Hi devs, validate-x86_64-darwin seems to be failing. I've restarted it when I came across the failure, but several small patches last night tripped on this. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman

Re: lint-submods-marge consistently failing when attempting to update Haddock

Ryan Scott writes: > The submodule linter appears to have been disabled in [1]. As Matthew notes > in [2], perhaps we should probably open a ticket to track how to restore it. > I opened a ticket [1] in my gitlab-migration project where I track this sort of administrative task. Cheers, - Ben

Re: lint-submods-marge consistently failing when attempting to update Haddock

The submodule linter appears to have been disabled in [1]. As Matthew notes in [2], perhaps we should probably open a ticket to track how to restore it. Ryan S. - [1] https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb39195c9d [2]

Re: lint-submods-marge consistently failing when attempting to update Haddock

Ben indicates (on the #ghc IRC channel) that he suspects something is amiss with the lint-submods-marge job. Ryan S. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

lint-submods-marge consistently failing when attempting to update Haddock

I've noticed that Marge's most recent batch is consistently failing after repeated attempts. Each time, the failure is only in the lint-submods-marge job. Here is an excerpt from the most recent failure [1]: Submodule update(s) detected in 1cd22260c2467650dde8811cc58e89594a016f43: utils

What to do if your hadrian build starts failing (supportedLlvmVersion)

If you see this message: Exit code: 1 Stderr: compiler/llvmGen/LlvmCodeGen/Base.hs:192:36: error: • Couldn't match expected type ‘Int’ with actual type ‘(Integer, Integer)’ • In the first argument of ‘LlvmVersion’, namely ‘(7, 0)’ In the expression: LlvmVersion (7,

Is your MR failing CI test T9630 or haddock.base?

Try rebasing! Due to some unfortunate circumstances the performance tests (T9630 and haddock.base) became fragile. This should be fixed, but you need to rebase off of the latest master (at at least c931f2561207aa06f1750827afbb68fbee241c6f) for the tests to pass. Happy Hacking, David

Re: CI failing

Indeed, this was a mistake and I put up a MR last night to hopefully fix it. https://gitlab.haskell.org/ghc/ghc/merge_requests/416 Cheers, Matt On Thu, Feb 21, 2019 at 8:40 AM Simon Peyton Jones wrote: > Ben, Matthew > > I believe that ‘master’ fails validate. See Trac #16346. > > The

CI failing

Ben, Matthew I believe that 'master' fails validate. See Trac #16346. The question is: how did it get past CI? The bug would only show up if -dcore-lint was on for libraries. Simon ___ ghc-devs mailing list ghc-devs@haskell.org

Re: CircleCI currently failing - possibly due to lack of disk space?

I'm looking into this. On 31/10/2018 14:40, Matthew Pickering wrote: The bridge which sends diffs to circleci is currently failing with the following error: {"args":["clone","ssh://g...@phabricator-origin.haskell.org:/diffusion/GHCDIFF/GHC-Different

CircleCI currently failing - possibly due to lack of disk space?

The bridge which sends diffs to circleci is currently failing with the following error: {"args":["clone","ssh://g...@phabricator-origin.haskell.org:/diffusion/GHCDIFF/GHC-Differentials.git","/tmp/ghc-diffs-1008dbb33e68821b"],"prog":&q

Re: CI builds failing

It should be ok with the following revert: https://git.haskell.org/ghc.git/commitdiff/0e37361392a910ccbbb2719168f4e8d8272b2ae2 On 17/04/2018 02:54, David Feuer wrote: On Monday, April 16, 2018 9:16:37 PM EDT Simon Peyton Jones wrote: I wonder if you are compiling with 8.2.1? It's broken.

RE: CI builds failing

I wonder if you are compiling with 8.2.1? It's broken. You need 8.2.2 | -Original Message- | From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of David Feuer | Sent: 16 April 2018 18:22 | To: ghc-devs@haskell.org | Subject: CI builds failing | | It looks like the

CI builds failing

It looks like the recent differential builds are all failing like this: compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] Defined but not used: ‘hsc_env’ | 79 | initializePlugins hsc_env df | ^^^ ghc: panic! (the 'impossible' happened) (GHC

T7050 failing

Hi Simon, Your recent "unpack datacons" patch (https://phabricator.haskell.org/rGHC9187d5fb1d3d38a4e607b0d61784c21447c8195b ) causes typecheck/should_compile/T7050 to loop. This was harder to discover because I had

Re: Failing Test Cases in HEAD

`devel2` compiles GHC with extra assertions and `./validate` doesn't do that. There's `./validate --slow` that enables extra assertions. AFAIK harbormaster (and most ghc-devs) only does `./validate` which explains how failures like this can sneak in. We used to have a travis build that did

Failing Test Cases in HEAD

In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails. That is while `./validate` passes. I am rather new to GHC code base, and not so familiar with its build and testing system. So I was wondering whether this is an intended behaviour (e.g., some

Re: external interpreter failing on Mac

.haskell.org/B16186, so this is at least not a > universal failure. Something specific to the version of GMP, or some other > external tool/library? > > On 14 June 2017 at 14:55, Richard Eisenberg <r...@cs.brynmawr.edu> wrote: > >> Hi devs, >> >> It seems every test run

Re: external interpreter failing on Mac

ast not a universal > failure. Something specific to the version of GMP, or some other external > tool/library? > > On 14 June 2017 at 14:55, Richard Eisenberg <r...@cs.brynmawr.edu > <mailto:r...@cs.brynmawr.edu>> wrote: > Hi devs, > > It seems every test

Re: external interpreter failing on Mac

June 2017 at 14:55, Richard Eisenberg <r...@cs.brynmawr.edu> wrote: > Hi devs, > > It seems every test run through the external interpreter is failing for me > on a Mac: > > => TH_mkName(ext-interp) 1 of 1 [0, 0, 0] > cd "./TH_mkName.run" && &quo

external interpreter failing on Mac

Hi devs, It seems every test run through the external interpreter is failing for me on a Mac: => TH_mkName(ext-interp) 1 of 1 [0, 0, 0] cd "./TH_mkName.run" && "/Users/rae/ghc/ghc/inplace/test spaces/ghc-stage2" -c TH_mkName.hs -dcore-lint -dcmm-lint -no

Re: Perf test failing: Trac #13668

Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: > Test perf/compiler/T9675 is failing (dramatically) for me. > See https://ghc.haskell.org/trac/ghc/ticket/13668 > Is it not failing for anyone else? > Why does https://perf.haskell.org/ghc/ not show it up? >

Re: Perf test failing: Trac #13668

Hi, Am Dienstag, den 09.05.2017, 07:39 + schrieb Simon Peyton Jones via ghc-devs: > Why does https://perf.haskell.org/ghc/ not show it up? I found that max_bytes_used perf tests are too unreliable and flaky, and add too much noise to the performance reports, so perf.haskell.org ignores

RE: Windows build failing in a new way

… .section .eh_frame,"a",@progbits Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 09 March 2017 16:38 To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Subject: Re: Windows build failing in a new way Hi Simon, As of this morning the Windows build was wor

RE: Windows build failing in a new way

Ben Gamari writes: > loneti...@gmail.com writes: > >> Ah great, >> >> Triples again.. I still wonder why it is suddenly an issue. We haven’t >> touched the .m4 file in a while and no one changed libffi either >> right? This is just like last time the normalization bit us.

RE: Windows build failing in a new way

loneti...@gmail.com writes: > Ah great, > > Triples again.. I still wonder why it is suddenly an issue. We haven’t > touched the .m4 file in a while and no one changed libffi either > right? This is just like last time the normalization bit us. Causing > days of broken builds on different targets

RE: Windows build failing in a new way

they were interested in. Why do we do the normalization? It doesn’t seem to give us any benefits at all.. Maybe we should stop doing it after the branch for 8.4? From: Ben Gamari Sent: Thursday, March 9, 2017 18:51 To: Phyx; Simon Peyton Jones; ghc-devs@haskell.org Subject: Re: Windows build failing

Re: Windows build failing in a new way

Phyx writes: > My CI server is also reproducing it while I also haven't been able to > locally. Weird indeed. > Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See [1]. Cheers, - Ben [1] https://phabricator.haskell.org/rGHCe901ed1c5d66 signature.asc

Re: Windows build failing in a new way

ual. I can't even build a GHC. > > Please, could someone fix this? I'm getting desperate. > > This is very odd; Harbormaster is also seeing it but I've been unable to > reproduce locally. It seems that the libffi build is failing but it's > quite unclear why it would

Re: Windows build failing in a new way

ly. It seems that the libffi build is failing but it's quite unclear why it would fail for you yet succeed for me. I'll try to reproduce on the Harbormaster machine. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing l

Re: Windows build failing in a new way

Checking again, I think something else is wrong I'll have to check later. Sorry, but that commit above is still good. If you are really stuck use that one. Tamar On Thu, 9 Mar 2017, 17:11 Phyx, wrote: > That said, running the build on HEAD it seems that the template

Re: Windows build failing in a new way

That said, running the build on HEAD it seems that the template haskell stuff committed today has broken the build again. I'd suggest checking out the commit in my previous email which is just a few hours old. And cleaning ghc-tarballs. As the error you seem to be getting is local. On Thu, 9 Mar

Re: Windows build failing in a new way

Hi Simon, As of this morning the Windows build was working fine https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 those are my nightly logs for last night at commit a02b80f That error seems to be coming from gcc and not ghc. We did update the crt and

Windows build failing in a new way

My windows build is more broken than usual. I can't even build a GHC. Please, could someone fix this? I'm getting desperate. Simon libtool: compile: C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w

Re: recomp001 failing on OSX for Phab:D2853

Whew! Glad to hear it. Thanks! - Luke Maurer University of Oregon maur...@uoregon.edu > On Jan 17, 2017, at 10:12 AM, Ben Gamari wrote: > > Luke Maurer writes: > >> Getting an odd test failure from Phab: >> >> @@ -1,2 +0,0 @@ >> - >>

Re: recomp001 failing on OSX for Phab:D2853

Luke Maurer writes: > Getting an odd test failure from Phab: > > @@ -1,2 +0,0 @@ > - > -C.hs:3:11: Module ‘B’ does not export ‘foo’ > Actual stderr output differs from expected: > *** unexpected failure for recomp001(normal) > >

recomp001 failing on OSX for Phab:D2853

Getting an odd test failure from Phab: @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ‘B’ does not export ‘foo’ Actual stderr output differs from expected: *** unexpected failure for recomp001(normal) https://phabricator.haskell.org/harbormaster/build/18499/?l=0 I can't explain how my changes would

OSX build failing

Hi all, The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 Should I revert the patch or is there a fix coming? Matt = commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 Author: Simon Marlow Date: Wed Nov 9 09:20:02 2016 + Remove

Re: OSX build failing

I now see D2705, sorry for the noise. Matt On Mon, Nov 14, 2016 at 9:00 PM, Matthew Pickering wrote: > Hi all, > > The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 > > Should I revert the patch or is there a fix coming? > > Matt > > = > >

Re: T12041 failing?

wrote: > Hmm. Yes, this is an (actually harmless) assertion failure if your build > has -DDEBUG on. I think it’s just a fluke that it’s only just started > failing. > > > > I’ll make a ticket for it; I don’t think it’s super-urgent. > > > > Simon > &g

RE: T12041 failing?

Hmm. Yes, this is an (actually harmless) assertion failure if your build has -DDEBUG on. I think it’s just a fluke that it’s only just started failing. I’ll make a ticket for it; I don’t think it’s super-urgent. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon

T12041 failing?

I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 + +++ /tmp/ghctest-uhJ8rt/test

Re: OSX failing

Matthew Pickering writes: > I will revert the commit which caused the build failure as I am not > able to fix it myself. It is hard to get this stuff right as > differentials are not built on OSX. > Thanks Matthew. I'll try to clean this up. Cheers, - Ben

OSX failing

All OSX builds are failing with rts/Linker.c:6371:1: error: error: unused function 'machoGetMisalignment' [-Werror,-Wunused-function] See eg https://phabricator.haskell.org/harbormaster/build/14551/ So I get lots of “Phab failed” messages, and am now simply deleting them, which rather defeats

RE: failing

Simon Peyton Jones writes: > Can you? With comment etc. > Of course. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org

RE: failing

yped.com> | Cc: ghc-devs@haskell.org | Subject: Re: failing | | On October 12, 2016 8:27:24 AM EDT, Simon Peyton Jones via ghc-devs | <ghc-devs@haskell.org> wrote: | >Ben: all builds are failing | >https://phabricator.haskell.org/harbormaster/ | >What’s up? I see a perf

Re: failing

On October 12, 2016 8:27:24 AM EDT, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote: >Ben: all builds are failing >https://phabricator.haskell.org/harbormaster/ >What’s up? I see a perf failure on T1969. Does not happen for me; and >is only in residency, so just

failing

Ben: all builds are failing https://phabricator.haskell.org/harbormaster/ What’s up? I see a perf failure on T1969. Does not happen for me; and is only in residency, so just bump it? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http

RE: SSH failing on Windows

| To: ghc-devs@haskell.org | Subject: Re: SSH failing on Windows | | Simon Peyton Jones via ghc-devs wrote: | | > | > But 'git push' says | > | > /c/code/HEAD$ git push | > | > Permission denied (publickey). | > | > fatal: Could not read from remote repository

Re: SSH failing on Windows

On 22. 8. 2016 12:15, Erik de Castro Lopo wrote: > And then I read the error message. That message suggests that the SSH key > is not known by the remote repository. Did you copy your SSH keys from > your old machine to your new machine? That was maybe also covered, see the quote below. > Simon

Re: SSH failing on Windows

Simon Peyton Jones via ghc-devs wrote: > > But 'git push' says > > /c/code/HEAD$ git push > > Permission denied (publickey). > > fatal: Could not read from remote repository. And then I read the error message. That message suggests that the SSH key is not known by the remote repository. Did

Re: SSH failing on Windows

Simon Peyton Jones via ghc-devs wrote: > Now my problem is that 'git push' doesn't work. My 'pushurl' is > pushurl = ssh://g...@git.haskell.org/ghc.git > which is correct I think. Try pushurl = g...@git.haskell.org/ghc.git I think the "ssh://" was for older versions of git.

topHandler03 failing now

Hey thomie, You recently changed topHandler03 to not ignore output. Unfortunately, on my Arch Linux box this causes the test to fail: --- ./topHandler03.run/topHandler03.stderr.normalised 2016-06-30 10:30:56.423442132 -0700 +++ ./topHandler03.run/topHandler03.run.stderr.normalised

Re: T8761 failing for ext-interp

Is it just perf-llvm? Does validate fail? What platform is this? On 26 June 2016 at 07:29, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > > Erik, could it be the same symptom as Edward is seeing here? > > > https://ghc.haskell.org/trac/ghc/ticket/12230 > >

Re: T8761 failing for ext-interp

Erik de Castro Lopo wrote: > > Erik, could it be the same symptom as Edward is seeing here? > > https://ghc.haskell.org/trac/ghc/ticket/12230 > > Yes it is. Just to provide a little more info, the tests I'm seeing fail (perf-llvm) are: TEST="TH_repUnboxedTuples T10828 T10596 TH_reifyMkName

Re: T8761 failing for ext-interp

Simon Marlow wrote: > Erik, could it be the same symptom as Edward is seeing here? > https://ghc.haskell.org/trac/ghc/ticket/12230 Yes it is. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/

Re: T8761 failing for ext-interp

Erik, could it be the same symptom as Edward is seeing here? https://ghc.haskell.org/trac/ghc/ticket/12230 On 26 June 2016 at 06:23, Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Richard Eisenberg wrote: > > > Phab tells us that T8761 is failing for

Re: T8761 failing for ext-interp

Richard Eisenberg wrote: > Phab tells us that T8761 is failing for the ext-interp way, as of > d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with > -fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229 Compling with BuildFlavour == perf-llvm results i

T8761 failing for ext-interp

Hi Simon, Phab tells us that T8761 is failing for the ext-interp way, as of d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with -fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229 Thanks, Richard ___ ghc-devs

Re: HEAD failing

08 T8308 [bad stdout] (normal) > Two things > > · would it be possible to remove the long /tmp/blah prefix? > Thomas argued that it is convenient to be able to cut-and-paste the path to a failing testcase. That being said, on balance I agree that it is a bit too noisy to be

RE: HEAD failing

Sent: 19 May 2016 13:16 | To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs | Subject: Re: HEAD failing | | Simon Peyton Jones <simo...@microsoft.com> writes: | | > Devs, | > I’m getting this on a clean build of HEAD on Linux | > | > Unexpected failures: |

HEAD failing

Devs, I’m getting this on a clean build of HEAD on Linux Unexpected failures: /tmp/ghctest/0MzM7D/1/2/3/./rts/T11108 T11108 [bad stdout] (normal) /tmp/ghctest/0MzM7D/1/2/3/./rts/T8308/T8308 T8308 [bad stdout] (normal) Two things · would it be possible to remove the long

RE: Harbourmaster is failing

** [includes/dist-derivedconstants/header/DerivedConstants.h] Error > 1 > > make: *** [all] Error 2 > > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon > Peyton Jones > Sent: 10 May 2016 09:44 > To: ghc-devs <ghc-devs@haskell.org> > Subject

RE: Harbourmaster is failing

rivedConstants.h] Error 1 make: *** [all] Error 2 From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones Sent: 10 May 2016 09:44 To: ghc-devs <ghc-devs@haskell.org> Subject: Harbourmaster is failing Lots of early Harbourmaster fails https://phabricator.haskel

Harbourmaster is failing

Lots of early Harbourmaster fails https://phabricator.haskell.org/harbormaster/build/11545/ Simon In file included from includes/Stg.h:213:0, from includes/Rts.h:30, from includes/dist-derivedconstants/header/tmp.c:13: includes/stg/Types.h:31:2: error: #import is a deprecated GCC

Build failing

A clean Windows build fails. See below. help! Simon rts\Linker.c:444:7: error: error: pointer type mismatch in conditional expression [-Werror] : pinfo->owner->fileName ^ rts\Linker.c:429:7: error: error: format '%ls' expects argument of type 'wchar_t *',

Re: Build failing

Hi Simon, I have made a diff to fix it but it hasn't been reviewed yet https://phabricator.haskell.org/D1878 Regards, Tamar Sent from my Mobile On Feb 2, 2016 12:07 PM, "Simon Peyton Jones" wrote: > A clean Windows build fails. See below. help! > > Simon > > > >

Re: Build failing

Phyx writes: > Hi Simon, > > I have made a diff to fix it but it hasn't been reviewed yet > https://phabricator.haskell.org/D1878 Thanks Phyx. I just fired off a validation build locally. I'll merge as soon as it passes. Cheers, - Ben signature.asc Description: PGP

Re: Build failing

Ben Gamari writes: > Phyx writes: > >> Hi Simon, >> >> I have made a diff to fix it but it hasn't been reviewed yet >> https://phabricator.haskell.org/D1878 > > Thanks Phyx. > > I just fired off a validation build locally. I'll merge as soon as it >

Library tests failing

I’m getting this collection of failing tests, all of a sudden (below). What’s up? I’m pretty sure it’s not my modifications. The failures ae => random1283(normal) 1 of 1 [0, 0, 0] cd . && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage2" -o random1283

Re: Phab failing to apply patches

Just to chime in here: I agree with Janek that the current requirement that Phab always cherry-picks changes against master is annoying. I have a limited amount of computing power available locally, and it's much easier to push to Phab than to slow down my primary dev machine for 2+ hours.

Re: Phab failing to apply patches

On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: > > If you are working from an old base commit, either rebase your patch > before > > submitting to Phabricator (painful? you will have to do it before pushing > > anyway, might as well do it now), or ignore the

Re: Phab failing to apply patches

> * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis > validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > * ask

Re: Phab failing to apply patches

On Sun, Jan 17, 2016 at 4:24 PM, Jan Stolarek wrote: > Can we somehow force Phab to apply a patch against a base commit from > which the patch was created? > I don't know about "somehow", maybe Austin knows a way. The current default should not be changed though, in my

Re: Phab failing to apply patches

> If you are working from an old base commit, either rebase your patch before > submitting to Phabricator (painful? you will have to do it before pushing > anyway, might as well do it now), or ignore the Harbormaster validate > result. I am typically working on some non-trivial features (ie.

Re: Phab failing to apply patches

On Mon, Jan 18, 2016 at 12:09 PM, Thomas Miedema wrote: > * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis >

Re: Phab failing to apply patches

he master branch, > > > and it will fail in the same way. > > > > > > Solution: rebase your patch onto master, and update the Diff. You'll > > > > notice > > > > > there are indeed merge problems. > > > > > > > > >

Phab failing to apply patches

It seems that Phab is once again failing to apply patches (eg. D1778, which built perfectly fine until latest update). Is anyone else experiencing this? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli

Re: Phab failing to apply patches

and update the Diff. You'll notice there are indeed merge problems. On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek <jan.stola...@p.lodz.pl> wrote: > It seems that Phab is once again failing to apply patches (eg. D1778, > which built perfectly fine > until latest update). Is

Re: Phab failing to apply patches

ll notice > there are indeed merge problems. > > > On Fri, Jan 15, 2016 at 6:49 PM, Jan Stolarek <jan.stola...@p.lodz.pl> > > wrote: > > It seems that Phab is once again failing to apply patches (eg. D1778, > > which built perfectly fine > >

arc land failing

I haven't been able to arc land in GHC for a while, it always complains about not being able to fast-forward, like this: $ git pull --rebase First, rewinding head to replay your work on top of it... Applying: Mask to avoid uncaught ^C exceptions $ arc land Landing current branch 'ghci-mask'.

Re: Travis builds failing

With a lot of help from @thomie .. On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, yay, travis is green again. Thanks to Alan for fixing this. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de •

Re: Travis builds failing

Hi, yay, travis is green again. Thanks to Alan for fixing this. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc

Re: Travis builds failing

I suspect this is different, I am building a local master now, at current HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find. Alan On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan Kim

Re: Travis builds failing

Looks like: collect2: ld terminated with signal 9 [Killed] which I'd say with fair certainty means that the jobs failed because the linker ran out of memory on Travis, and the OOM killed it. So, that's a thing now. Perhaps for travis builds, we could disable SplitObjs by default to relieve the

Re: Travis builds failing

On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp: I don't think there's any built-in way to do that in the current testsuite infrastructure, other than setting THREADS=1, which, if it isn't set

Re: Travis builds failing

I don't think there's any built-in way to do that in the current testsuite infrastructure, other than setting THREADS=1, which, if it isn't set already, would probably push us back over the Travis build limit. I wonder if we could just ask if they'd increase the limit for our project... On Mon,

  1   2   >