[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)
Wed, 07 Aug 2019 23:42:39 -0400
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
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
>> 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
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
> - 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:
> 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.
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
> Thanks for the review.