Update Request: pandoc 3.7.0.2 → 3.10

[NicoWeio]

Nixpkgs version

• Unstable (25.11)

Package name

pandoc

Upstream version

3.8.2.1

Nixpkgs version

3.7.0.2

Changelog

https://pandoc.org/releases.html

Additional context

Fixes #381996

Notify maintainers

@maralorn

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this package update does not yet exist in an open pull request or in Nixpkgs Unstable.
• I assert that this is not a duplicate of any known issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[maralorn]

Hey there, updates to Haskell packages are being worked on on the haskell-updates branch. The process works in a way that we don’t bump individual packages manually but automatically in bulk. It will just be a little while until we can merge the update.

[sternenseemann]

Stackage LTS 26 won't update to pandoc 3.8, so we'd need to do something akin to hledger.

[doronbehar]

What's the status of this? I'm waiting for Pandoc 3.8 for such a long time now... 🙏

[sternenseemann]

We are still tracking Stackage LTS 24. Stackage Nightly has pandoc 3.9. There are two options/timelines for getting pandoc 3.9 into Nixpkgs.

• We upgrade to Stackage Nightly which I've been interested in doing for a while now. The past tells us that this may take 1-3 months with current Haskell maintainer availability or even longer if we encounter bigger roadblocks.

• We stop tracking Stackage Nightly for pandoc or make the latest version of pandoc available at the top level (while keeping the Stackage LTS version in haskellPackages which may be easier). pandoc is a nontrivial project with a lot of interdependent packages that don't have any goals of API stability that also has a lot of reverse dependency, so this change likely means a lot of initial and ongoing maintenance work. For this reason, I've proposed (a long time ago: RFC: Provide latest versions of some Haskell executables at the top level #190542) that we do this if a maintainer of pandoc commits to this ongoing work.

  Otherwise, it will be a lot of additional work that I personally (given how things have been going) will be doing which will further delay Haskell package set updates etc. pp. Even though I really think we ought to provide a more up to date version of pandoc, I desperately want to avoid that situation since we already lack the time to maintain the Haskell package set to the high standard we had been managing a few years ago (and on a personal note, I can feel myself loosing motivation), so I don't want to commit the Haskell team to more work if we can avoid it.

If anyone interested wants to pursue a low commitment first step, they can look into getting haskellPackages.pandoc_3_9 to build on current haskell-updates (or pandoc_3_8_3 on master, but that probably won't last…).

[doronbehar]

The build log if anyone has an idea how to fix it:

Running phase: setupCompilerEnvironmentPhase
Build with /nix/store/xva1k28a3vq0lkzf9f6q43krfq1lnmgr-ghc-9.10.3.
Running phase: unpackPhase
unpacking source archive /nix/store/qbazdi6d50d5m5d0dmyp4skbfr00jgq6-pandoc-3.9.tar.gz
source root is pandoc-3.9
setting SOURCE_DATE_EPOCH to timestamp 1000000000 of file "pandoc-3.9/xml-light/Text/Pandoc/XML/Light/Types.hs"
Running phase: patchPhase
Running phase: compileBuildDriverPhase
setupCompileFlags: -package-db=/build/tmp.Sl9ij1WKHf/setup-package.conf.d -threaded
[1 of 2] Compiling Main             ( /nix/store/4mdp8nhyfddh7bllbi7xszz7k9955n79-Setup.hs, /build/tmp.Sl9ij1WKHf/Main.o )
[2 of 2] Linking Setup
Running phase: updateAutotoolsGnuConfigScriptsPhase
Running phase: configurePhase
configureFlags: --verbose --prefix=/nix/store/zjlq7v8y6jg1sp97rsmjragmgikz9bly-pandoc-3.9 --libdir=$prefix/lib/$compiler/lib --libsubdir=$abi/$libname --datadir=/nix/store/aky8052jifdrjsq4v6zb0zwr4wsqsvmm-pandoc-3.9-data/share/ghc-9.10.3 --with-gcc=gcc --package-db=/build/tmp.Sl9ij1WKHf/package.conf.d --ghc-option=-j6 --ghc-option=+RTS --ghc-option=-A64M --ghc-option=-RTS --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --enable-split-sections --enable-library-stripping --enable-executable-stripping -f-trypandoc --extra-lib-dirs=/nix/store/5qrvz1d1f813wcw6b752d4daaqxxbd1r-ncurses-6.6/lib --extra-lib-dirs=/nix/store/5mnq195cx3cagnpbbvf5ncbp4fjgy0sz-libffi-3.5.2/lib --extra-lib-dirs=/nix/store/588hnj4f64i2bbdjk1mjzif778dk4zp4-elfutils-0.194/lib --extra-lib-dirs=/nix/store/wqikjqrnbynh44y0nfr16ynyq1g891wf-gmp-with-cxx-6.3.0/lib --extra-lib-dirs=/nix/store/hddsa82i6slh4saws93hj7aaaym2ir1b-numactl-2.0.18/lib
Using Parsec parser
Configuring pandoc-3.9...
Error: [Cabal-8010]
Encountered missing or private dependencies:
    citeproc >=0.13 && <0.14,
    texmath >=0.13.1 && <0.14,
    typst >=0.9 && <0.10
CallStack (from HasCallStack):
  dieWithException, called at libraries/Cabal/Cabal/src/Distribution/Simple/Configure.hs:1457:11 in Cabal-3.12.1.0-7e3b:Distribution.Simple.Configure

[raj-magesh]

We upgrade to Stackage Nightly which I've been interested in doing for a while now.

@sternenseemann Is there a particular reason the default package set to the LTS version? I would have expected that NixOS Unstable would pull things from the Nightly set.

[maralorn]

Well, nixos unstable is the branch where we prepare the stable releases. We can't just magically switch to a different ghc+snapshot on branch-off. So the argument unstable ~ nightly is kinda moot.

There are two reasons:

1. Normally at the beginning of a stackage cycle, nightly contains quite few packages and a lot of non-stackage packages might still be incompatible with the coupled ghc+libs. So, it gives less quality at higher effort.

2. Switching to a newer stackage snapshot is a lot of effort which always rests on very few shoulders so we tend to wait until we must.

That being said, as discussed here, switching a bit earlier would generally be a good idea and we'd like to.

[raj-magesh]

I see, thanks for the explanation!

[jolars]

I am guessing this will be closed by #521260, right?

[sternenseemann]

Yes.