pandoc build failure

[dweber@…]

OSX 10.5.8, MacPorts 1.8.1

--->  Fetching pandoc
--->  Attempting to fetch pandoc-1.2.1.tar.gz from http://distfiles.macports.org/pandoc
--->  Verifying checksum(s) for pandoc
--->  Extracting pandoc
--->  Configuring pandoc
--->  Building pandoc
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_pandoc/work/pandoc-1.2.1" && /usr/bin/make -j8 build-all PREFIX=/opt/local GHC=/opt/local/bin/ghc GHC_PKG=/opt/local/bin/ghc-pkg " returned error 2
Command output: /opt/local/bin/ghc -package Cabal Setup.hs -o ./setup
make: *** No rule to make target `man/man1/hsmarkdown.1', needed by `build-doc'.  Stop.
make: *** Waiting for unfinished jobs....

[jmroot (Joshua Root)]

Don't forget to assign to the maintainer.

[rs573@…]

Cc Me!

[na0vt8ua@…]

Cc Me!

[chris@…]

Cc Me!

[macports@…]

This doesn't happen if you change the pandoc release to '1.3' in the Portfile, but the current release is 1.6 so that's just a stopgap, and the maintainer already indicated that a change in maintainership would be great :-)

Regardless, you can try that, but then you'll potentially run in to #24405 as something about ghc loading objects isn't working quite right, right now

[macports@…]

Cc Me!

[jgm@…]

Hi, I'm still listed as the official maintainer, it seems, but I no longer use macports and would like someone else to take this over. (I'm the upstream developer of pandoc.)

If someone is trying to get a Portfile working for a recent version of pandoc, I'd be more than happy to help figure out what is going wrong. You can email me directly or write to pandoc-discuss@…. Note that the Makefile has been removed from recent versions of pandoc, which use a pure Cabal build system. It would be easy, though, to write a new Makefile that runs the Cabal commands. Again, I'm willing to help, but I'd love it if someone who uses it could take over the port.

[macports@…]

I have to admit I was only trying it to get the "progit" book source turned into PDF - I would be seriously yak-shaving if that small task into maintainership of tools for a language I don't even know :-).

That said, in a large sense the real problem to me seems to be that there are multiple delivery styles for the same language and it's libraries - there is the Haskell Platform .dmg, and a Haskell package manager internal to the language, and there is also the platform packaging system (macports).

Without a huge injection of work to bring the macports style of Haskell installation up to date (platform is still on 2009-2-2! the libraries are aging etc) it seems like the best recommendation is to just mark the macports stuff deprecated and tell people honestly that for a good Haskell experience they should grab the Haskell platform .dmg, and use Cabal to internally manage Haskell libraries.

I think that would solve the general Haskell ghc problem as it appears to be related to CPU exec protection features that have probably been solved in the year or two since the version of GHC in macports was released.

CPAN, PEAR and rubygems all do the equivalent I believe - and the ones that do also have platform-native package system "mirrors" of their packages have only managed by coding up tools that take the language-native packaging and auto-generate platform-native packages from it. In that sense you'd need the Haskell Platform source code to have Portfile generation built in to it, and Cabal would have to be capable of generating Portfiles (or Makefiles) directly that would work - then the whole system could be in macports but with no special effort

That has nothing to do with what anyone is asking :-), but I thought I'd mention it since I'd help package a bit perhaps but it just seems like a "try harder" strategy with this style as opposed to a "try smarter" strategy and I'd put money on anyone messing with a smaller-community language (like Haskell) is more of a "try smarter" type...

Cheers!

[jgm@…]

I agree with all of this. It's best to mark the pandoc port deprecated, since the recommended install path is now via Haskell platform dmg + cabal. The way forward for Haskell on macports is, as you suggest, for someone to construct a cabal2port program that automatically constructs Portfiles from cabal packages. Most likely a lot of this could be carried over from the successful ​http://hackage.haskell.org/package/cabal2arch.

[jmroot (Joshua Root)]

Set to nomaintainer in r75490.

[singingwolfboy@…]

I'm the latest maintainer for the pandoc port, and I recently updated it to version 1.8.0.1. The haskell portgroup seems to take care of most of the gruntwork shuttling between Macports and Cabal, and pandoc now uses that portgroup. If anyone can reproduce this problem, please comment on the ticket. If a reasonable length of time has passed and no one has reproduced this problem on 1.8.0.1, I'm going to assume switching to the haskell portgroup fixed this problem, and close this ticket.

[ryandesign (Ryan Carsten Schmidt)]

It is still happening to at least one user; see #29996.

[jmroot (Joshua Root)]

That user hadn't selfupdated and was building version 1.2.1.

[lincoln@…]

Cc Me!

[lincoln@…]

Cc Me!