[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36807] Please merge wip-haskell-updates (Re: [bug#36807] remove obs
[bug#36807] Please merge wip-haskell-updates (Re: [bug#36807] remove obsolete broken haskell packages)
Tue, 6 Aug 2019 09:04:39 +0200
> On 6. Aug 2019, at 06:29, Timothy Sample <address@hidden> wrote:
>> #36663: adding elm compiler dependencies (just a few extra ghc
> 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
> 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
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.