Re: Bug#559978: pandoc FTBFS
+++ Joachim Breitner [Feb 27 10 18:53 ]:
> Hi Jonas,
>
> Am Montag, den 22.02.2010, 12:43 -0800 schrieb John MacFarlane:
> > +++ Joachim Breitner [Feb 22 10 21:21 ]:
> > > > Template Haskell is a standard language feature. My worry, though,
> > > > was that if we did not support all architectures on which pandoc
> > > > 0.46 built, pandoc would never migrate from unstable to testing.
> > > > Am I wrong about this?
> > >
> > > If pandoc can not be built on some arches, then the release team will
> > > probably ok the removal of the pandoc package on the broken arches,
> > > allowing the transition. But you could retry building pandoc with the
> > > new ghc6 compiler, maybe it works now.
> >
> > Note: the next release of pandoc (1.5) will not depend on Template
> > Haskell. I plan to release this in the next month or two.
>
> I usually like to avoid having to wait for new upstream versions to get
> rid of a issue. Would it be possible that you make sure the pandoc
> package builds successfully with ghc6-6.12 and the updated libraries, at
> least on the arches with Template Haskell support?
Joachim and Jonas:
Although pandoc 1.3, the latest packaged for debian, may build with
ghc6-6.12, the resulting executable won't handle UTF-8 correctly,
because of the double-encoding problem one gets when using both
System.IO.UTF8 and GHC6.12. (I posted about this problem earlier to
debian-haskell, since it may affect a few other packages as well.
I also wrote to the author of utf8-string with some suggestions
about how to solve the problem, but as far as I know, no action has been
taken.)
I used CPP to work around this problem in pandoc 1.4, the latest
released version. Since there are a couple other problems with that
release, I asked Jonas to hold off packaging until 1.5 was ready.
I don't want to hold things up too much, so I could expedite work
on 1.5 and try to release it in a week or so, so packaging could
proceed.
John
Reply to: