[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [core-updates-frozen] Haskell for i686-linux: report

From: Timothy Sample
Subject: Re: [core-updates-frozen] Haskell for i686-linux: report
Date: Sun, 05 Dec 2021 11:47:02 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)


zimoun <> writes:

> After some Cuirass monitoring and restarted some unexpected failures,
> the situation for ghc-* on i686-linux is the same as the one from
> current master.

I took a few minutes to triage these.  Most of them are fixable.

> Two packages are broken in core-updates-frozen and not in master:
>  1. ghc-ncurses

Looks like this is due to an ncurses API update:

AFAICS, both scroll and ghc-ncurses are abandoned.  In the case of
scroll, you could say that it’s “finished” I guess, since it’s a game.
I bet it would work fine if we drop the “KEY_EVENT” line in
“lib/UI/NCurses/Enums.chs”.  Otherwise, we could consider dropping these
two packages.

>  2. ghc-lukko

Upstream bug:

The consensus so far is disable OFD locking on 32-bit platforms using
the “-ofd-locking” configure flag.

> These test suite failures require some investigations.  Many other ghc-*
> packages too:
>  - ghc-sha

This one is an out of memory error.  Not sure what to do.

>  - ghc-validty

Upstream bug:

There’s a patch there to fix the tests for 32-bit machines.

>  - ghc-bloomfilter

Upstream bug:

The tests are bounds checking using an overflowed literal: 0xffffffff.
Other distros get rid of the check, but the literal could be fixed, too,
as explained in the bug report.

>  - ghc-tar

Upstream bug: (from rekado!)

There’s no patch from upstream.  It looks like a simple word size
mistake in the tests like ghc-validity or ghc-bloomfilter.

>  - ghc-llvm-hs

Not sure about this one.

>  - ghc-lucid

This one I’ve seen before!  Upstream has trouble with nondeterministic
ordering of output HTML attributes.  I guess running the tests on a
32-bit machine exposes some more of these problems.  Patching the tests
to allow different orders would fix it.


It would be good to fix these, but it would be better to update our
whole Haskell stack.  That’ll have to be something to attempt once c-u-f
is merged.

-- Tim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]