Re: Fedora 33 Self-Contained Change proposal: GHC 8.8 and Haskell Stackage LTS 16

[Jens-Ulrik Petersen]

On Fri, Jun 26, 2020 at 10:44 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/GHC_8.8_and_LTS16 

On behave of the Haskell SIG I am happy to announce that ghc-8.8.4 and
Stackage 16.5 based Haskell packages have now been pushed to Rawhide.

Jens

Fedora 33 Self-Contained Change proposal: GHC 8.8 and Haskell Stackage LTS 16

[Jens-Ulrik Petersen]

On Tue, Jul 21, 2020 at 5:48 PM Jens-Ulrik Petersen <petersen(a)redhat.com&gt;
wrote:

>  On Fri, Jun 26, 2020 at 10:44 PM Ben Cotton
> <bcotton(a)redhat.com&gt; wrote:
>
> > https://fedoraproject.org/wiki/Changes/GHC_8.8_and_LTS16
>
>
>  On behave of the Haskell SIG I am happy to announce that ghc-8.8.4 and
>  Stackage 16.5 based Haskell packages have now been pushed to Rawhide.
>  
Just a summary with some more details:

- we got the latest stable 8.8.4 ghc release from last week (as of Stackage
16.6, its ghc version is still officially 8.8.3, whereas Nightly has 8.10.1)
  - I got seriously delayed last week due to problems building ghc on
s390x, but fortunately fbrnch helped speed up all the package building in
parallel, which made up for it in time.
- Stackage LTS version is 16.5 (released the weekend before last)
- basically no build failures, yay: except ghc-gtksourceview2 which is
largely deprecated anyway: I plan to retire it but a bug has been filed.
- I fixed ghc-cabal-helper, despite the heavier new deps
- further using -O0 I managed to enable a few packages that had been
excluded from armv7hl (Agda, hlint, also needed for pandoc!) and ppc64le
(gtk2hs stack).
- subpackaged library doc subpackages will become noarch after the mass
rebuild (ie fix is already in ghc-rpm-macros)
- hedgewars needs a patch to build against network-3 (I already filed a
heads-up bug some weeks ago)

Still lots of help is needed to unbundle the growing list of subpackaged
dependencies from packages: see https://pagure.io/haskell-sig/issue/4 (info
there needs minor refresh for f33).
Subpackaging, a workaround for lack of package review resources (though
special thanks to zebob for his continued support with many package
reviews), is actually a big overhead when it comes to updating all the
packages (though I have improved cabal-rpm's handling of subpackaging
considerably), so getting rid of them would be a really big help. We should
continue to work on that continuously.

Let me know if you have any feedback or queries.

Thanks, Jens