[bug#36807] remove obsolete broken haskell packages

[bug#36807] remove obsolete broken haskell packages

[Robert Vollmert]

This series removes some outdated packages that don’t build and
aren’t depend on.

[bug#36807] [PATCH] gnu: Remove ghc-regex-tdfa-rc (broken and unused)

[Robert Vollmert]

It doesn't build, has no reverse dependencies, and is deprecated
upstream.

* gnu/packages/haskell.scm (ghc-regex-tdfa-rc): Remove package.
---
 gnu/packages/haskell.scm | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index d8c574b3f5..c5de8f2c10 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -3033,30 +3033,6 @@ Haskell library @code{regex-base}.")
 @code{regex-posix} to replace @code{Text.Regex}.")
     (license license:bsd-3)))
 
-(define-public ghc-regex-tdfa-rc
-  (package
-    (name "ghc-regex-tdfa-rc")
-    (version "1.1.8.3")
-    (source
-     (origin
-       (method url-fetch)
-       (uri (string-append
-             "https://hackage.haskell.org/package/regex-tdfa-rc/regex-tdfa-rc-"
-             version
-             ".tar.gz"))
-       (sha256
-        (base32
-         "1vi11i23gkkjg6193ak90g55akj69bhahy542frkwb68haky4pp3"))))
-    (build-system haskell-build-system)
-    (inputs
-     `(("ghc-regex-base" ,ghc-regex-base)))
-    (home-page
-     "https://hackage.haskell.org/package/regex-tdfa")
-    (synopsis "Tagged DFA regex engine for Haskell")
-    (description "A new all-Haskell \"tagged\" DFA regex engine, inspired by
-@code{libtre} (fork by Roman Cheplyaka).")
-    (license license:bsd-3)))
-
 (define-public ghc-regex-tdfa-text
   (package
     (name "ghc-regex-tdfa-text")
-- 
2.21.0

[bug#36807] [PATCH] gnu: Remove ghc-haddock-test (broken and unused)

[Robert Vollmert]

The package doesn't build, has no reverse dependencies, and is
deprecated upstream.

* gnu/packages/haskell.scm (ghc-haddock-test): Remove packge.
---
 gnu/packages/haskell.scm | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index c5de8f2c10..bf1d1669f5 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -1184,28 +1184,6 @@ the ‘haddock’ package.")
 documentation-generation tool for Haskell libraries.")
     (license license:bsd-3)))
 
-(define-public ghc-haddock-test
-  (package
-    (name "ghc-haddock-test")
-    (version "0.0.1")
-    (source
-     (origin
-       (method url-fetch)
-       (uri (string-append "https://hackage.haskell.org/package/"
-                           "haddock-test/haddock-test-"
-                           version ".tar.gz"))
-       (sha256
-        (base32
-         "1ax8fnfrwx66csj952f3virxzapipan9da7z5l1zc12nqkifbs7w"))))
-    (build-system haskell-build-system)
-    (inputs
-     `(("ghc-xml" ,ghc-xml)
-       ("ghc-syb" ,ghc-syb)))
-    (home-page "http://www.haskell.org/haddock/")
-    (synopsis "Test utilities for Haddock")
-    (description "This package provides test utilities for Haddock.")
-    (license license:bsd-3)))
-
 (define-public ghc-haddock
   (package
     (name "ghc-haddock")
-- 
2.21.0

[bug#36807] remove obsolete broken haskell packages

[Timothy Sample]

Hi Robert,

Robert Vollmert <rob@vllmrt.net> writes:

> This series removes some outdated packages that don’t build and
> aren’t depend on.

I remember that we intended to remove these last year.  Indeed, Ricardo
mentioned it when we were finishing up the upgrade to GHC 8.4:

    https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00330.html

Based on that, we could also get rid of “ghc-packedstring” if it doesn’t
have any dependants.

Now for my usual commit message nit-picking.  :)  You should drop the
parenthetical “broken and unused” note and add a period to the end of
the first line, like this:

    gnu: Remove ghc-regex-tdfa-rc.

One of the commits says “It...” and the other says “This package...”.
They might as well be the same.  Lastly, it’s usually “remove variable”
instead of “remove package”.

Other than that, LGTM.  Thanks!  (Do you have commit access now or
should I push these?)


-- Tim

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

[Robert Vollmert]

Hi all, Timothy,

On 25. Jul 2019, at 15:29, Timothy Sample <samplet@ngyro.com> wrote:
> Other than that, LGTM.  Thanks!  (Do you have commit access now or
> should I push these?)

I do have commit access now, but for the moment I’m keeping to the
branch wip-haskell-updates.

Thus, I’d ask you (or someone) to merge that (or the parts you deem
appropriate). I’ve incorporated your comments, and removed
ghc-packedstring. In addition, the branch incorporates some other
patchsets:

#36493: updating GHC-included haskell dependencies (this one is already
        in core-updates)
#36562: downgrade ansi-terminal to be compatible with the package set
#36663: adding elm compiler dependencies (just a few extra ghc packages)
#36692: GHC version 8.6.5 (just as a package for now, not used to build
        anything)
#36807: this bug report, removing three deprecated packages
no ticket: Skip tests for three Haskell packages that fail on i686 only
        (and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell.

Cheers
Robert

> Hi Robert,
> 
> Robert Vollmert <rob@vllmrt.net> writes:
> 
>> This series removes some outdated packages that don’t build and
>> aren’t depend on.
> 
> I remember that we intended to remove these last year.  Indeed, Ricardo
> mentioned it when we were finishing up the upgrade to GHC 8.4:
> 
>    https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00330.html
> 
> Based on that, we could also get rid of “ghc-packedstring” if it doesn’t
> have any dependants.

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

[Robert Vollmert]

Hi all, Timothy,

On 25. Jul 2019, at 15:29, Timothy Sample <samplet@ngyro.com> wrote:
> Other than that, LGTM.  Thanks!  (Do you have commit access now or
> should I push these?)

I do have commit access now, but for the moment I’m keeping to the
branch wip-haskell-updates.

Thus, I’d ask you (or someone) to merge that (or the parts you deem
appropriate). I’ve incorporated your comments, and removed
ghc-packedstring. In addition, the branch incorporates some other
patchsets:

#36493: updating GHC-included haskell dependencies (this one is already
        in core-updates)
#36562: downgrade ansi-terminal to be compatible with the package set
#36663: adding elm compiler dependencies (just a few extra ghc packages)
#36692: GHC version 8.6.5 (just as a package for now, not used to build
        anything)
#36807: this bug report, removing three deprecated packages
no ticket: Skip tests for three Haskell packages that fail on i686 only
        (and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell.

Cheers
Robert

> Hi Robert,
> 
> Robert Vollmert <rob@vllmrt.net> writes:
> 
>> This series removes some outdated packages that don’t build and
>> aren’t depend on.
> 
> I remember that we intended to remove these last year.  Indeed, Ricardo
> mentioned it when we were finishing up the upgrade to GHC 8.4:
> 
>    https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00330.html
> 
> Based on that, we could also get rid of “ghc-packedstring” if it doesn’t
> have any dependants.

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

[Timothy Sample]

Hi Robert,

Robert Vollmert <rob@vllmrt.net> writes:

> Hi all, Timothy,
>
> On 25. Jul 2019, at 15:29, Timothy Sample <samplet@ngyro.com> wrote:
>> Other than that, LGTM.  Thanks!  (Do you have commit access now or
>> should I push these?)
>
> I do have commit access now, but for the moment I’m keeping to the
> branch wip-haskell-updates.

OK.  I thought that might be the case.  Thanks for letting me know.

> Thus, I’d ask you (or someone) to merge that (or the parts you deem
> appropriate).

Cool!  I’m in the process of looking everything over.  In the meantime,
I have some early questions and comments.

> I’ve incorporated your comments, and removed
> ghc-packedstring. In addition, the branch incorporates some other
> patchsets:
>
> #36493: updating GHC-included haskell dependencies (this one is already
>         in core-updates)

I think it makes sense to wait for the core-updates merge (which
shouldn’t be too far out).

> #36562: downgrade ansi-terminal to be compatible with the package set

I’ve reordered these changes a bit, and they are now ready to go.

> #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*”.

> #36807: this bug report, removing three deprecated packages

Since we already had a back-and-forth for these, they’re almost
certainly fine.

> 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.

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.

Thanks for putting this branch together!


-- Tim

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

[Robert Vollmert]

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

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

[Robert Vollmert]

Oh, I meant to ask:

On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> wrote:
> Robert Vollmert <rob@vllmrt.net> writes:
> 
>> Hi all, Timothy,
> 
> Cool!  I’m in the process of looking everything over.  In the meantime,
> I have some early questions and comments.
> 
>> I’ve incorporated your comments, and removed
>> ghc-packedstring. In addition, the branch incorporates some other
>> patchsets:
>> 
>> #36493: updating GHC-included haskell dependencies (this one is already
>>        in core-updates)
> 
> I think it makes sense to wait for the core-updates merge (which
> shouldn’t be too far out).

Why? Shouldn’t substitutes be available since CI built the branch successfully?

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Robert Vollmert <rob@vllmrt.net> writes:

> Oh, I meant to ask:
>
> On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> wrote:
>> Robert Vollmert <rob@vllmrt.net> writes:
>> 
>>> Hi all, Timothy,
>> 
>> Cool!  I’m in the process of looking everything over.  In the meantime,
>> I have some early questions and comments.
>> 
>>> I’ve incorporated your comments, and removed
>>> ghc-packedstring. In addition, the branch incorporates some other
>>> patchsets:
>>> 
>>> #36493: updating GHC-included haskell dependencies (this one is already
>>>        in core-updates)
>> 
>> I think it makes sense to wait for the core-updates merge (which
>> shouldn’t be too far out).
>
> Why? Shouldn’t substitutes be available since CI built the branch successfully?

core-updates is still waiting for a full-rebuild change, and the CI is
currently unusable, so merging might take a month or more still.

Getting this in 'master' meanwhile would be great, especially for i686
users :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 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 <rob@vllmrt.net> writes:

> Hi Timothy,
>
>> On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> 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:
>       glasgow-haskell-bugs@haskell.org
>     
>     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

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

[Timothy Sample]

Hi Robert and Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Robert Vollmert <rob@vllmrt.net> writes:
>
>> Oh, I meant to ask:
>>
>> On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> wrote:
>> 
>>> I think it makes sense to wait for the core-updates merge (which
>>> shouldn’t be too far out).
>>
>> Why? Shouldn’t substitutes be available since CI built the branch successfully?
>
> core-updates is still waiting for a full-rebuild change, and the CI is
> currently unusable, so merging might take a month or more still.
>
> Getting this in 'master' meanwhile would be great, especially for i686
> users :-)

I stand corrected!  :)  I cherry-picked these commits from core-updates.

Thanks for chiming in, Marius.


-- Tim

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

[Timothy Sample]

Timothy Sample <samplet@ngyro.com> writes:

> 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.  :)

Including this one!

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi Robert and Marius,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Robert Vollmert <rob@vllmrt.net> writes:
>>
>>> Oh, I meant to ask:
>>>
>>> On 6. Aug 2019, at 06:29, Timothy Sample <samplet@ngyro.com> wrote:
>>> 
>>>> I think it makes sense to wait for the core-updates merge (which
>>>> shouldn’t be too far out).
>>>
>>> Why? Shouldn’t substitutes be available since CI built the branch successfully?
>>
>> core-updates is still waiting for a full-rebuild change, and the CI is
>> currently unusable, so merging might take a month or more still.
>>
>> Getting this in 'master' meanwhile would be great, especially for i686
>> users :-)
>
> I stand corrected!  :)  I cherry-picked these commits from core-updates.
>
> Thanks for chiming in, Marius.

Thanks for merging, and huge thanks to Rob for untangling the Haskell
packages.

I have one comment about the series: we've disabled tests on some
packages that have been broken "forever" on i686.  It would be better to
do so selectively on just the affected architectures.  I.e.:

 #:tests? (if (string-prefix? "i686" (%current-system))
              #f
              #t)

Preferably with a comment about why they need to be disabled.  That way,
we will still notice when something breaks on other architectures.  Can
you try it Rob?

Thanks,
Marius

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Robert Vollmert]

On 8. Aug 2019, at 15:12, Marius Bakke <mbakke@fastmail.com> wrote:
> I have one comment about the series: we've disabled tests on some
> packages that have been broken "forever" on i686.  It would be better to
> do so selectively on just the affected architectures.  I.e.:
> 
> #:tests? (if (string-prefix? "i686" (%current-system))
>              #f
>              #t)
> 
> Preferably with a comment about why they need to be disabled.  That way,
> we will still notice when something breaks on other architectures.  Can
> you try it Rob?

I don’t intend to, because I think the effort is better spent elsewhere.
But do make the change if you like!

The rough plan from my point of view would be to aim for an upgrade of
the haskell packages to build with ghc-8.6 from a recent stackage LTS
set, and reevaluate skipped tests across the set while doing that or
once that’s done.

Cheers
Robert

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

[Timothy Sample]

Hi,

Robert Vollmert <rob@vllmrt.net> writes:

> On 8. Aug 2019, at 15:12, Marius Bakke <mbakke@fastmail.com> wrote:
>> I have one comment about the series: we've disabled tests on some
>> packages that have been broken "forever" on i686.  It would be better to
>> do so selectively on just the affected architectures.  I.e.:
>> 
>> #:tests? (if (string-prefix? "i686" (%current-system))
>>              #f
>>              #t)
>> 
>> Preferably with a comment about why they need to be disabled.  That way,
>> we will still notice when something breaks on other architectures.  Can
>> you try it Rob?
>
> I don’t intend to, because I think the effort is better spent elsewhere.
> But do make the change if you like!
>
> The rough plan from my point of view would be to aim for an upgrade of
> the haskell packages to build with ghc-8.6 from a recent stackage LTS
> set, and reevaluate skipped tests across the set while doing that or
> once that’s done.

This was in the back of my mind, too.  Stackage LTS 14.0 (built on top
of GHC 8.6.5) was released three days ago.  Upgrading will involve
sweeping changes to the whole set of Haskell packages, giving us lots of
opportunities to revisit these failing tests.  If we still have problems
with the i686 tests, we can make them conditional then.

Thanks for pointing this out though, Marius.  I had thought about making
them conditional when reviewing, but I second guessed myself because we
have a lot of packages with comments like “tests fail on architecture X”
followed by an absolute “#:tests? #f”.  If this comes up in the future,
I’ll just go ahead and make the tests conditional.


-- Tim

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi,
>
> Robert Vollmert <rob@vllmrt.net> writes:
>
>> On 8. Aug 2019, at 15:12, Marius Bakke <mbakke@fastmail.com> wrote:
>>> I have one comment about the series: we've disabled tests on some
>>> packages that have been broken "forever" on i686.  It would be better to
>>> do so selectively on just the affected architectures.  I.e.:
>>> 
>>> #:tests? (if (string-prefix? "i686" (%current-system))
>>>              #f
>>>              #t)
>>> 
>>> Preferably with a comment about why they need to be disabled.  That way,
>>> we will still notice when something breaks on other architectures.  Can
>>> you try it Rob?
>>
>> I don’t intend to, because I think the effort is better spent elsewhere.
>> But do make the change if you like!
>>
>> The rough plan from my point of view would be to aim for an upgrade of
>> the haskell packages to build with ghc-8.6 from a recent stackage LTS
>> set, and reevaluate skipped tests across the set while doing that or
>> once that’s done.
>
> This was in the back of my mind, too.  Stackage LTS 14.0 (built on top
> of GHC 8.6.5) was released three days ago.  Upgrading will involve
> sweeping changes to the whole set of Haskell packages, giving us lots of
> opportunities to revisit these failing tests.  If we still have problems
> with the i686 tests, we can make them conditional then.
>
> Thanks for pointing this out though, Marius.  I had thought about making
> them conditional when reviewing, but I second guessed myself because we
> have a lot of packages with comments like “tests fail on architecture X”
> followed by an absolute “#:tests? #f”.  If this comes up in the future,
> I’ll just go ahead and make the tests conditional.

OK.  Thanks to both of you for clarifying :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]