This removes 'ldgallery' from nixpkgs.
It remains available through the Nix Flake provided by ldgallery.
The package of its "compiler" part was already marked as broken due to
dependencies having gone out of sync with the rest of the Haskell
packages.
The package of its "viewer" part also got out of sync due to changes
in JS dependency manager.
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.
ghc-source-gen being broken is the norm now, as it only supports
GHC < 9.4. To keep tabs on it still (it is required for HLS some of the
time), we add it to release-haskell.nix.
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.)
When building gi-gtk with ghc-9.6.1 and ghc-9.6.2 there are errors
like this:
<no location info>: error:
attempting to use module ‘gi-gtk-3.0.41-DcfU7A0rbDCAyPkJQEwKC:GI.Gtk.Interfaces.Buildable’ (./GI/Gtk/Interfaces/Buildable.hs) which is not loaded
The errors can be avoided by using -j1, which is unfortunate for
gi-gtk because it has 708 modules to build.
The ghc gitlab issue is: https://gitlab.haskell.org/ghc/ghc/-/issues/23392
This applies the Cabal pkgconfig workaround to taffybar and all of its
pkgconfig-using dependencies.
A typical example of the build error looks like this:
Package libpcre2-8 was not found in the pkg-config search path.
The main problem was GHC exceeding the Hydra output limit with profiling
libs on aarch64-linux which made us disable the feature. Nowadays the
limit is 3GB, the GHC output is a bit over 2GB, so easily under the
limit.
aarch64-darwin uses a different codegen backend and was never really
affected by the problem: Its output with profiling enabled is around
1.6GB.
Consequently we can enable profiling for all platforms again, as we have
no output size issues for those we build on Hydra.
Thanks to flokli for helping me track down these up to date numbers.
Some packages cabal-install needed a certain version range (cabal-install-solver
and resolv) have versions incompatible with these in Stackage LTS 21. We can,
however, easily provide the necessary ones.
Additionally, we clean up some old resolv related overrides that are no longer
necessary or we no longer care about (being able to build cabal-install with
GHC 8.6, namely).
For GHC >= 9.0, foldable1-classes-compat is a test only dependency. For GHC < 9.0,
OneTuple also depends on it. It is important to add it to the library's build
depends as well, so it gets propagated properly to builds of packages that depend
on base-compat-batteries (or foldable1-classes-compat will appear as broken to
Cabal).
