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

[Timothy Sample]

Hi Robert,

I pushed my touched-up version of your branch to master!  (See commits
a62ddb748f–caa366ec23.)  Now I will enjoy closing all those patches.  :)

I hope all my changes are okay.  Besides the changes to “ghc-8.6”, I
mostly altered formatting, descriptions, and commit messages to better
fit our conventions.  I’ve added a few comments below.

Robert Vollmert <address@hidden> writes:

> Hi Timothy,
>
>> On 6. Aug 2019, at 06:29, Timothy Sample <address@hidden> wrote:
>> 
>>> #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

Personally I find them about the same, but my impression is that the
“substitute*” approach is more common.  I used it to try to be more
consistent.

> - patch doesn’t fail silently

This is a real problem, and there was a recent discussion on changing
the semantics of “substitute*” to fix this (I can’t find it now,
though).  We would probably find a lot of unnecessary calls to
“substitute*” if we could easily see when it does nothing.

>>> 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:
>       address@hidden
>     
>     Test suite doctests: FAIL
>
> I spent a bit of time digging, then gave up.

That’s no problem.  I just wanted to be sure that you looked and didn’t
see anything obvious.  We can investigate it later or it may get fixed
upstream.

> Thanks for the review.

You’re welcome!


-- Tim