Age | Commit message (Collapse) | Author |
|
There's no need to second-guess upstream versioning -- we shouldn't be
covering for upstream sometimes tagging releases a couple commits after
they've bumped it in the cabal file.
|
|
|
|
Although correct, this was breaking some automated tooling, and is
unnecessary regardless
|
|
Transitive deps of extra/pandoc, so we need to pull them in explicitly.
|
|
The default makepkg configuration sets LDFLAGS but not LD.
GHC used to take this as its cue to select its own choice of LD.
However GHC would *not* check that its choice of LD supports LDFLAGS.
This is a problem for dependencies with C components, which get linked
using this LD.
A fix[1] for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's
installed using the current ghcup HEAD (starting with 7a684ad[2]) will
have `--disable-ld-override` passed, which also fixes the issue.
[1] - https://gitlab.haskell.org/ghc/ghc/-/issues/24565
[2] - https://github.com/haskell/ghcup-hs/issues/1032
|
|
Thanks to @alerque for reminding me of the makedep requirement
|
|
Cf discussion in https://github.com/jgm/pandoc/issues/9248.
Given upstream preferences in re workflow, this is the best we can do to
signal version bump breakage
|
|
|
|
|
|
|
|
Upstream accepted the patch
|
|
Commits 3692a1d..c5287e9 introduce a dependency on pandoc-lua-marshal
0.1.0.1
However, this bound change was only reflected in stack.yaml, not
pandoc.cabal
For some reason stack.yaml isn't picked up by `stack build`, so this
breaks the build
Reported upstream as https://github.com/jgm/pandoc/issues/7721
|
|
|
|
|