[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#36807] Please merge wip-haskell-updates (Re: [bug#36807] remove obs

From: Robert Vollmert
Subject: [bug#36807] Please merge wip-haskell-updates (Re: [bug#36807] remove obsolete broken haskell packages)
Date: Tue, 6 Aug 2019 09:04:39 +0200

Hi Timothy,

> On 6. Aug 2019, at 06:29, Timothy Sample <address@hidden> wrote:
>> #36663: adding elm compiler dependencies (just a few extra ghc
>> packages)
> These commits seem to be in the wrong order.  I think I can untangle
> them, though.
>> #36692: GHC version 8.6.5 (just as a package for now, not used to build
>>        anything)
> I made some bigger changes here.  Mostly, I made use of
> “substitute-keyword-arguments” to reuse more code from “ghc-8.4”.
> Why do you use “patch” instead of “substitute*” to disable the failing
> tests?  I see from your previous patches that you used to do it with
> “substitute*”.

It would be ok to go back to the old state. I moved to a patch over the
process of getting the build to pass, which involved skipping more tests.
That said, substitute has several downsides compared to patches:
- patch is easier to read
- patch doesn’t fail silently

>> no ticket: Skip tests for three Haskell packages that fail on i686 only
>>        (and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell.
> This seems reasonable to me, though I suppose it would be better to only
> skip them when building for i686.  It looks like we only do this
> rarely (e.g., the “icu4c” package), so maybe it’s not a big deal.

I’ll keep that in mind for next time I run into a similar issue.

> Is there any more info about “ghc-trifecta”?  The other two have nice
> comments that tell me that upstream is aware of the problem, and that it
> might be fixed in the future.

That one is a rather opaque build failure kind of thing related to doctests:

    They fail to build on i686:
    During interactive linking, GHCi couldn't find the following symbol:
    This may be due to you not asking GHCi to load extra object files,
    archives or DLLs needed by your current session.  Restart GHCi, specifying
    the missing library using the -L/path/to/object/dir and -lmissinglibname
    flags, or simply by naming the relevant files on the GHCi command line.
    Alternatively, this link failure might indicate a bug in GHCi.
    If you suspect the latter, please send a bug report to:
    Test suite doctests: FAIL

I spent a bit of time digging, then gave up.

Thanks for the review.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]