Re: Please merge wip-haskell-updates (Re: [bug#36807] remove obsolete broken haskell packages)

[Robert Vollmert <rob@vllmrt.net>]

Hi Timothy,

> On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> 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:
    
    doctests:
    ByteCodeLink.lookupCE
    During interactive linking, GHCi couldn't find the following symbol:
      lenszm4zi16zi1zmJLUwQ4zzqmnaKkc25AByaCJ_ControlziLensziTH_makeClassy_closure
    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:
      glasgow-haskell-bugs@haskell.org
    
    Test suite doctests: FAIL

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

Thanks for the review.

Robert