Unfortunately hspec 2.7 no longer compiles with GHC >= 9.4, so we hide
it in the Hydra jobset. It is preserved nonetheless, as it is used by
ghcjs (which still uses hspec 2.7 and GHC 8.10.7).
Since 500b36d057, there is a more recent
version of skylighting and skylighting-core available than Stackage LTS
contains. We'll have to manually provide matching versions for pandoc
3.1.6 again.
The main motivation for this is that the latest versions of hspec-core
and hspec-expectations got out of sync due to an unlucky timing on the
hackage snapshot update. As a consequence, we weren't able to build
cabal-install in some package sets. Additionally, this brings a version
of futhark that can be built with the lsp version we ship.
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
and maintainers/scripts/haskell/regenerate-hackage-packages.nix.
Additional changes:
* Adapt to new xhtml version (still doesn't match the version normally
shipped by the respective GHC as a core library).
* Adapt to new versions of hspec* and pandoc
all-cabal-hashes: 2023-06-28T16:36:39Z -> 2023-07-19T20:56:38Z
This commit has been generated by
* maintainers/scripts/haskell/update-hackage.sh
* maintainers/scripts/haskell/update-stackage.sh
* maintainers/scripts/haskell/regenerate-hackage-packages.sh
Additionally, the following manual changes are included:
* Delete now obsolete overrides for
- base-compat, base-compat-batteries (new release in stackage)
- cmark (new release in stackage)
- skylighting (newer release than 0.13.3 in stackage)
- optics (new release in stackage)
* Adjust to new versions for
- hspec, hspec-core, hspec-discover, hspec-expectations
- fourmolu
- pandoc
- doctest
!fixup stackage
Building base-compat-batteries-0.12.2 against OneTuple == 0.4.* as we do
for GHC < 9.0 could lead to confusing results for users of
Data.Tuple.Compat. Thankfully upstream has provided a solution they are
satisfied with and released it as 0.12.3 to which we preemptively
upgrade (but it should enter Stackage LTS 21 soon enough)
See https://github.com/haskell-compat/base-compat/pull/92.
This reverts commit 54ebdad42d.
I've verified that the (small) test suite still passed and had a cursory
look at the code for the bindings. cmark doesn't use any internal Text
modules nor seems to make any specific assumptions about Text's internal
encoding. The interfaces used are Data.Text.Encoding and
Data.Text.Foreign. From the latter, only functions relating to CString
are used which have used UTF-8 encoding already for text < 2.0. (It
stands to reason that cmark may actually benefit from the internal
encoding change in 2.0.)
