| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
These are also deps of pandoc and are therefore already implied.
The GMP dep is common to all Haskell programs, the zlib dep _might_ be a
transitive dep via the pandoc dependency itself, but I'm not sure.
|
|
Forgot to in 2904ec8c1a55735a8df89ed5206c6084ec36dfe1
|
|
The only part we actually must have is that the resolver uses ghc>=9.6.5
Since the upstream resolver does so, don't touch it.
(Taking this position since upstream specifies different versions from
lts, which causes spurious needs for version bumps)
Reverts: fd3228748b392fad36689df44d23c07fa7953830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also bump to lts-22.22 to pick up ghc-9.6.5 instead of specifying
manually
|
|
|
|
Use it for pandoc bumping as well (instead of blind sed scripts), taking
care that pandoc-cli, pandoc-lua-engine are also in pandoc's repo
|
|
|
|
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
|
|
.gitattributes are useful for local configuration, but they shouldn't
have been checked in
|
|
Cf RFC#16
|
|
Upstream releases aren't monotonic wrt vercmp -- eg they release
v0.3.16.0f < v0.3.17.0 < v0.3.17.0a
whereas vercmp would sort this
v0.3.16.0f < v0.3.17.0a < v0.3.17.0
After considering multiple solutions, noticing that the final alphabetic
component seems to be a patch version not reflected in
`pandoc-crossref.cabal`, decided to just drop that component.
The information provided in it is redundant with the .rCOUNT.gSHA
component, and none of the ways of massaging it into an acceptable
pkgver left me confident they'd solved the mononicity problem.
As a bonus, this solution will not create spurious downgrade warnings.
|
|
|
|
Programmatically edit stack.yaml for version bumping, makes maintenance
easier. If yq is undesired, it can be edited out and replaced with a
patch -- the edits should be pretty self-explanatory.
This bumps the LTS used to 22.13, which point-bumps GHC
|
|
|
|
|
|
Forced compilation with ghc-9.6.3 to reduce maintenance burden
(not needing multiple ghc versions installed)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Included patches:
- Upstream PR#348: Fix pandoc breaking some tests' expected output
|
|
|
|
|
|
|
|
|
|
|
|
Technically, should provide the PVP-appropriate bump over latest stable.
However, that's a) hard to compute in a simple bash script and b)
unlikely to be a problem, especially for executable (ie, nonlibrary)
dependencies
|
|
Upstream updated buildplan to new pandoc version
|
|
Previous config also killed diffs
|
|
|
|
Force usage of happy-1.20.0, since happy-1.21.0 in nightly does not
build
|