Bug#1053686: pandoc: cannot fulfill the build dependencies

[John MacFarlane]

Removing lua support would be most unfortunate!  If you need help from upstream 
in getting things to work, let me know.

Bug#1023149: marked as done (pandoc FTBFS on i386)

[John MacFarlane]

Just an observation: adding the -O0 option here will create an unoptimized 
build, which will run more slowly.  So this is definitely not a patch that 
should remain more than short-term.

I have no idea what this issue is, by the way.  We regularly test pandoc 
upstream against ghc versions 8.6.5, 8.8.4, 8.10.7, 9.2.3, and 9.4.2, and I've 
never seen this issue.

> On Nov 24, 2022, at 1:39 AM, Debian Bug Tracking System 
>  wrote:
> 
> The patch below workarounds the issue, which indicates that it might
> be a bug in the compiler and not a problem in pandoc?
> 
> Short-term it might even be good enough to unblock migration of several
> packages to testing.
> 
> --- debian/rules.old  2022-10-30 17:52:59.643347191 +
> +++ debian/rules  2022-10-30 17:54:14.347251214 +
> @@ -192,6 +192,10 @@
> DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param 
> -optcggc-min-expand=10 -O0"
> endif
> 
> +ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386))
> +DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-O0"
> +endif
> +
> DEB_SETUP_GHC_CONFIGURE_ARGS += $(if $(filter 
> nocheck,$(DEB_BUILD_OPTIONS)),,-ftests)
> 
> DEB_INSTALL_DOCS_ALL += README.md
> 17.1.1-1.1) unstable; urgency=low
> .
>   * Non-maintainer upload.
>   * Workaround i386 FTBFS with -O0. (Closes: #1023149)
> Checksums-Sha1:
> b8474b357393a855e985003374b89cf1d8cc566a 9172 pandoc_2.17.1.1-1.1.dsc
> 14914bf918799cd45b75e9c71748f5a1c13acc2b 59012 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> Checksums-Sha256:
> ccb354586541dfc3e0b121b527d10bdbc39f8369b3d7072276bee7558f56fa3e 9172 
> pandoc_2.17.1.1-1.1.dsc
> 07ef9d2654ba4cbdf018ca6c691b5330348ee5c0fd85813cf4dc91d46822127f 59012 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> Files:
> ccfd9b94d62c2efea06540f914c9e8b1 9172 text optional pandoc_2.17.1.1-1.1.dsc
> 9d1452b2c9c481ef8740f81480b2b81b 59012 text optional 
> pandoc_2.17.1.1-1.1.debian.tar.xz
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmN4118ACgkQiNJCh6LY
> mLF08Q//e3i2jHi91hJSH7HCyAGhCQq8KrnZWwp99EK/MgdAqDcQtLc3NR/APnUc
> DwuzqDUA1cHJb/say/MeU2tdj3k9sBAD+MzhP150u1LZQKxFnpmbQLS42e545r1g
> T2lCBNsXUleK5a3fZCjx9gwuvJCTRZX0h6HEWooirCy8e6AY0K2nptWbEiiApSDk
> q1rcgyaFjNijYldYfPxPo9DXz6cdK1TTjlyAxxcvM7EJGgGUX7ROB6FKN73Y6mU8
> DjSu4LyrgK9vmGPU55VhiKrfDQy6zQbEzhU+ovmSkul3gVSbGarutvbbfi2/FleJ
> 7MKpqgNb0mO/a9vNQ+69BJwVkYje35XtBfNNVoUjAqrgbNuCb5n8wuTYIFDyPudu
> MEFWPt615Pxn8395wvQyGBxVLbpOWwH/PPRGBm3G69n6fYXF2NcyLzCyXD7vyIjl
> FIH5K76q06E5CkTnFweXxSiDKFs/X30V4BOYiyShrLAAPBVQNYcEGFtPw7RRRrMZ
> HYnjShF5J3/+14J5ACBrO4czZhROkwxyeEAaRcGqCQevj+uJuMk3RQiiTr1zcdID
> cFYwlj9xXZZwGqGfYgcuc+w4iV1tp6OnrbDfSjEphC0hrT26dxpoT0EUv1+dKChx
> MiZsYj/5nkjpLG8MIA/MpIU9mOiAuo/bhf/3fzmw7WQSWDWDxHk=
> =PDz7
> -END PGP SIGNATURE-
> 

Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0

[John MacFarlane]

A note from upstream, in case it's helpful:  we haven't depended
on cmark-gfm since pandoc 2.10.1 (released a year and a half
ago).  If you could move to a more recent version of pandoc, this
would avoid the problem entirely.  I'm aware that issues of
policy and packaging may make this difficult, though.

Bug#977339: pandoc: `data-dir` or `XDG_DATA_HOME` don't appear to work for --defaults

[John MacFarlane]

The man page says:

> The file will be searched for first in the working directory, and then in
> the `defaults` subdirectory of the user data directory

It looks as if you've put your options.yaml directly in the user
data directory rather than in the defaults subdirectory of that
directory: try `$HOME/.local/share/pandoc/defaults/options.yaml`.

Bug#963128: pandoc: conversion from docbook: missing space between firstname and lastname

[John MacFarlane]

Indeed, this also happens with the current dev version of
pandoc.  If you want this to be fixed, you'll get better
results if you submit the bug report for pandoc upstream
on our tracker: https://github.com/jgm/pandoc/issues.

Bug#753299: marked as done (libghc-highlighting-kate-dev: Highlighting Ocaml fails)

[John MacFarlane]

Note that highlighting-kate is deprecated and has been replaced
by the skylighting library, used in more recent versions of
pandoc.

Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]

[John MacFarlane]

Jonas,
I don't understand how this is possible: don't all the
debian packages that depend on pandoc-types get compiled
against the same version of pandoc-types?
Best,
John

Jonas Smedegaard  writes:

> Quoting Eric Marsden (2020-06-12 16:08:52)
>> Package: pandoc-sidenote
>> Version: 0.20.0-1
>> 
>> When invoking pandoc-sidenote as a pandoc filter, it generates an error 
>> related to "incompatible API versions".
>> 
>>     % pandoc --filter pandoc-sidenote -o /tmp/foo.html foo.md
>>     pandoc-sidenote: Error in $: Incompatible API versions: encoded with 
>> [1,17,5,4] but attempted to decode with [1,20].
>>     CallStack (from HasCallStack):
>>      error, called at ./Text/Pandoc/JSON.hs:107:64 in 
>> pandoc-types-1.20-Ip2ZGM2tgGt4TDYVgvP7zF:Text.Pandoc.JSON
>>     Error running filter pandoc-sidenote:
>>     Filter returned error status 1
>> 
>> 
>> Architecture is amd64. Pandoc version is 2.5-3+b1. Reverting to the 
>> previous version 0.19.0.0-2+b4 works fine.
>
> Interesting!  Looks like pandoc and pandoc-sidenote was compiled with 
> different versions of pandoc-types, and strongly depend on that being 
> identical at runtime.
>
> I will look into having pandoc provide a virtual package indicating its 
> "ABI" of which pandoc-types it was compiled against, and then have 
> pandoc-sidenote depend on that ABI.
>
> Thanks for reporting!
>
>  - Jonas
>
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[John MacFarlane]

As you can see from pandoc's changelog, the man reader was only
introduced in version 2.4.  You're using an older version, so...

Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure

[John MacFarlane]

Thank you for your report.  If you'd run a more recent version of
pandoc, you'd have seen the additional warning:

[WARNING] Could not deduce format from file extension .man
  Defaulting to markdown

which should explain things.

Add '-f man' to your command line and it should work fine. (At
least it does with the most recent version.)

Bug#944978: pandoc: fails to convert horizontal rules from markdown to PDF (through LaTeX)

[John MacFarlane]

This is a known issue:
https://github.com/jgm/pandoc/issues/5801
It will be fixed in the upcoming pandoc 2.8 release.

A simple workaround which could be backported
would be to add this line to the default latex
template (default.latex):

 \renewcommand{\linethickness}{0.05em}

Bug#923418: Introduces spurious whitespace after parentheses

[John MacFarlane]

This looks like

https://github.com/jgm/pandoc/issues/4635

which is fixed in recent versions nof pandoc.
2.2.2+

Martin Michlmayr  writes:

> Package: pandoc
> Version: 2.2.1-3+b2
>
> pandoc introduces a space after parentheses under certain
> circumstances:
>
> 65576:tbm@jirafa: ~] cat pandoc
>
> this is a test (e.g.
> why is there a space after the parenthesis?).
>
> 65577:tbm@jirafa: ~] cat pandoc | pandoc
> this is a test ( e.g. why is there a space after the parenthesis?).
>
> -- 
> Martin Michlmayr
> https://www.cyrius.com/

Bug#910280: pandoc: Please reduce the binary size

[John MacFarlane]

Jonas Smedegaard  writes:

> The proper solution here, I guess (but am not expert in Haskell so may 
> be wrong) is to switch to using shared linking, so that 5 Haskell 
> binaries will not consume 5 x the disk space of the parts reused among 
> them.

Yes, in theory.  But this didn't work well in practice
when arch linux tried it.  It meant that installing
pandoc forced installation of a very large number of
dynamic libraries, and people really didn't like this.

https://www.reddit.com/r/haskell/comments/6jj8ha/whats_going_on_in_archlinux_pandoc_requires_1gb/

Bug#910280: pandoc: Please reduce the binary size

[John MacFarlane]

I'm happy to leave this issue up to the Debian
maintainer, since the upx compression would need to
be done in the packaging process and doesn't involve
upstream.

I tested upx compression (with --best --ultra-brute)
on macOS.  Time for 'pandoc --version' went from 0.031s
without compression to 0.756s with compression.  This
is potentially an issue for some users of pandoc
(particularly people who shell out to pandoc to
convert small bits of text).  Offering a compressed
version as an option sounds like a good idea.

Bug#901306: pandoc: FTBFS on armhf: ghc: panic

[John MacFarlane]

It would be worth reporting this as a bug to the ghc
tracker, as requested in the message.

Emilio Pozuelo Monfort  writes:

> Source: pandoc
> Version: 2.2.1-1
> Severity: serious
>
> pandoc now FTBFS on armhf with a ghc panic:
>
> [112 of 131] Compiling Text.Pandoc.Readers.HTML ( 
> src/Text/Pandoc/Readers/HTML.hs, dist-ghc/build/Text/Pandoc/Readers/HTML.p_o )
> ghc: panic! (the 'impossible' happened)
>   (GHC version 8.2.2 for arm-unknown-linux):
>   piResultTy
>   Addr#
>   String
>   Call stack:
>   CallStack (from HasCallStack):
> prettyCurrentCallStack, called at 
> compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
> callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in 
> ghc:Outputable
> pprPanic, called at compiler/types/Type.hs:949:35 in ghc:Type
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> Full logs at https://buildd.debian.org/status/logs.php?pkg=pandoc=armhf
>
> Emilio

Bug#888468: pandoc: please support new YAML fields "front/back-notice" for LaTeX and HTML5 output

[John MacFarlane]

Francesco Poli  writes:

> On Fri, 01 Jun 2018 10:20:34 +0200 Jonas Smedegaard wrote:
> If you don't want the Debian package to diverge from the upstream
> behavior, please, at least, forward my wishlist bug report (with my
> patch) upstream!
> This could speed up the upstream patch adoption process, I guess...

As upstream maintainer, I agree with Jonas's decision not to diverge
from upstream.  And I think Jonas is already doing enough work
packaging pandoc; it's not his job to forward this to upstream.

If you care about the feature, you may propose it upstream on the
pandoc-discuss mailing list or the jgm/pandoc issue tracker on GitHub.
That is the way it will be most convenient for upstream developers
to consider it.

Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing

[John MacFarlane]

I don't understand this error.  InvalidYaml *is* a constructor for the
type ParseException in Data.Yaml (yaml package).  So it's not clear why
the compiler would complain about it being used as a "constructor-like
thing."

What version of ghc is being used to compile?

What version of the Haskell yaml package is being used?

Emilio Pozuelo Monfort  writes:

> Source: pandoc
> Version: 2.2-1
> Severity: serious
>
> pandoc fails to build on armel and armhf:
>
> [117 of 131] Compiling Text.Pandoc.Readers.Markdown ( 
> src/Text/Pandoc/Readers/Markdown.hs, 
> dist-ghc/build/Text/Pandoc/Readers/Markdown.o )
>
> src/Text/Pandoc/Readers/Markdown.hs:275:20: error:
> * Identifier `InvalidYaml' used as a constructor-like thing
> * In the pattern:
> InvalidYaml (Just YamlParseException {yamlProblem = problem,
>   yamlContext = _ctxt,
>   yamlProblemMark = YamlMark 
> {yamlLine = yline,
>   
> yamlColumn = ycol}})
>   In a case alternative:
>   InvalidYaml (Just YamlParseException {yamlProblem = problem,
> yamlContext = _ctxt,
> yamlProblemMark = YamlMark 
> {yamlLine = yline,
> 
> yamlColumn = ycol}})
> -> logMessage
>  $ CouldNotParseYamlMetadata
>  problem
>  (setSourceLine
> (setSourceColumn pos (sourceColumn pos + ycol))
> (sourceLine pos + 1 + yline))
>   In a stmt of a 'do' block:
> case err' of
>   InvalidYaml (Just YamlParseException {yamlProblem = problem,
> yamlContext = _ctxt,
> yamlProblemMark = YamlMark 
> {yamlLine = yline,
> 
> yamlColumn = ycol}})
> -> logMessage
>  $ CouldNotParseYamlMetadata
>  problem
>  (setSourceLine
> (setSourceColumn pos (sourceColumn pos + ycol))
> (sourceLine pos + 1 + yline))
>   _ -> logMessage $ CouldNotParseYamlMetadata (show err') pos
> |
> 275 |InvalidYaml (Just YamlParseException{
> |^...
>
>
> Full logs at https://buildd.debian.org/status/package.php?p=pandoc=sid
>
> Emilio
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), 
> (500, 'unstable-debug'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
>
> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#897451: pandoc: beamer output no longer works

[John MacFarlane]

It may be that the default beamer template now includes a package
that already loads geometry.

See
https://tex.stackexchange.com/questions/266995/latex-error-option-clash-for-package-geometry

If so, you should be able to work around this by doing this instead:

header-includes:
- '\geometry{margin=1in}'


Benoît  writes:

> Package: pandoc
> Version: 2.2-1
> Severity: normal
>
> Dear Maintainer,
>
> Rendering into beamer no longer works (was ok this since 1.7):
>
>
> ---
> author: Benoît
> institution: ABC
> title: ABC D
> date: 2018
> theme: Hannover
> toc: true
> papersize: a4
> geometry: margin=1.5cm
> pagenumbering: true
> ---
>
>
> # Hello
> Hello
>
>
>
> $ pandoc --slide-level 2 -t beamer a.md -o a.pdf
> Error producing PDF.
> ! LaTeX Error: Option clash for package geometry.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...
>
> l.44 \newif
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages pandoc depends on:
> ii  libc62.27-3
> ii  libffi6  3.2.1-8
> ii  libgmp10 2:6.1.2+dfsg-3
> ii  liblua5.1-0  5.1.5-8.1+b2
> ii  libpcre3 2:8.39-9
> ii  libyaml-0-2  0.1.7-2
> ii  pandoc-data  2.2-1
> ii  zlib1g   1:1.2.11.dfsg-1
>
> pandoc recommends no packages.
>
> Versions of packages pandoc suggests:
> pn  context
> pn  ghc
> ii  groff  1.22.3-10
> ii  librsvg2-bin   2.40.20-2
> ii  nodejs 8.9.3~dfsg-12
> pn  pandoc-citeproc
> ii  perl   5.26.2-2
> pn  php
> ii  python 2.7.15~rc1-1
> ii  r-base-core3.4.4-1
> ii  ruby   1:2.5.1
> ii  texlive-latex-extra2018.20180416-1
> ii  texlive-latex-recommended  2018.20180416-1
> pn  texlive-luatex 
> pn  texlive-xetex  
> ii  wkhtmltopdf0.12.4-1
>
> -- debconf-show failed

Bug#856123: pandoc: Convert markdown to bad docbook for non-ascii titles

[John MacFarlane]

I'd say it's a dblatex problem.  DocBook 4.2 spec says


ID is an identifying string for the element. It must be
unique at least within the document and must begin with a
letter.


Nothing said here about a limitation to ASCII.  And here the
XML file clearly indicates that the encoding is UTF-8.
In addition, `xmlstarlet val` says that the XML file is valid.

Pandoc has an `--ascii` option to force ASCII output, but
currently it only works for HTML output, not DocBook. This
could be changed, but please submit an enhancement request
to pandoc's own upstream bug tracker,
https://github.com/jgm/pandoc/issues, rather than here.

Bug#828167: pandoc: in RST to HTML, no URI duplication in relative links when reference omitted

[John MacFarlane]

Thanks for your very helpful report. I have fixed this bug (commit
d283f9c864fc4a9ed8ffa4711dda9014b886149b).  The fix is
available now in the dev version and will be in the next
release.

+++ Christian Heller [Jun 25 16 18:24 ]:

Package: pandoc
Version: 1.16.0.2~dfsg-1
Severity: normal

Dear Maintainer,

"What led up to the situation?"

Using pandoc to convert a ReStructured Text document to HTML.

"What exactly did you do (or not do) that was effective (or
ineffective)?"

I have a file test.rst that contains this string: ``_

I run pandoc test.rst > test.html

"What was the outcome of this action?"

I cat test.html and get this content:



"What outcome did you expect instead?"

I expected test.html to contain something like this:

foo

I expected this because

1) the RST specification states:

"The reference text may also be omitted, in which case the URI will be
duplicated for use as the reference text. This is useful for relative
URIs where the address or file name is also the desired reference text:

See ``_ or ``__
for details."

()

2) docutils' rst2html (which I don't want to due to other faults of it)
actually produces something like this, namely:

foo

-- System Information:
Debian Release: 8.5
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=, LC_CTYPE= (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pandoc depends on:
ii  libc62.19-18+deb8u4
ii  libffi6  3.1-2+b2
ii  libgmp10 2:6.0.0+dfsg-6
ii  liblua5.1-0  5.1.5-7.1
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libyaml-0-2  0.1.6-3
ii  pandoc-data  1.16.0.2~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  etoolbox   
pn  pandoc-citeproc
pn  texlive-latex-recommended  
pn  texlive-luatex 
pn  texlive-xetex  
pn  wkhtmltopdf

-- no debconf information

Bug#797469: pandoc 1.15.0.6~dfsg-1 doesn't ship manpages for pandoc and pandoc_markdown

[John MacFarlane]

Upstream here:  This should be very easy to fix.
The pandoc.1 man page is right in the tarball, in the man
directory.

Bug#800701: pandoc: suppresses ~code~ when converting Org-mode to HTML(5)

[John MacFarlane]

This bug was fixed in pandoc over a year ago:
https://github.com/jgm/pandoc/issues/1345

+++ Karl Voit [Oct 02 15 18:35 ]:

Package: pandoc
Version: 1.12.4.2~dfsg-1+b14
Severity: important

Dear Maintainer,

I ran unit-tests for (py)pandoc on my new Debian machine. In contrast to
oldstable, pandoc now deletes text when converting from Org-mode to HTML or
HTML5.

  * What exactly did you do (or not do) that was effective (or
ineffective)?

I am using this short example file:

| vk@sherri ~2d % cat source.org
| foo ~bar~ *baz*
| vk@sherri ~2d %

  * What was the outcome of this action?

Converting via pandoc (or pypandoc) deletes the "bar" text from the content:

| vk@sherri ~2d % pandoc -f org -t html source.org
| foo  baz
| vk@sherri ~2d % pandoc -f org -t html5 source.org
| foo  baz
| vk@sherri ~2d %

  * What outcome did you expect instead?

With a prior version of Debian oldstable, I got a different result (from my
memory, code-tags were used definitely according to my unit tests):

| foo bar baz



-- System Information:
Debian Release: 8.2
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pandoc depends on:
ii  libc62.19-18+deb8u1
ii  libffi6  3.1-2+b2
ii  libgmp10 2:6.0.0+dfsg-6
ii  libicu52 52.1-8+deb8u3
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3
ii  libyaml-0-2  0.1.6-3
ii  pandoc-data  1.12.4.2~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  etoolbox   
pn  pandoc-citeproc
ii  texlive-latex-recommended  2014.20141024-2
pn  texlive-luatex 
ii  texlive-xetex  2014.20141024-2

-- no debconf information

--
Karl Voit

Bug#772962: pandoc: HTML table conversion fairly broken

[John MacFarlane]

This regression was fixed in the 1.13 release. Here is the patch that fixes it:
https://github.com/jgm/pandoc/commit/31fd843133ee9482b6af353a7d793cae18929425

It would be great if this patch could be applied to debian's package.  And even 
better if debian could package 1.13.1!

+++ Manfred Stock [Dec 12 14 15:58 ]:

Package: pandoc
Version: 1.12.4.2~dfsg-1+b14
Severity: normal

Dear Maintainer,

I recently tried the gitit-wiki from testing to see if HTML table handling will
be better than in the version from Wheezy. However, I quickly noticed an issue
with a simple table that was working on the Wheezy-version of gitit. This
problem can also be reproduced with the 'pandoc' command line tool: Given the
following table in 'input.html':

--8
table
 tbody
   tr
 td1/td
 td2/td
   /tr
   tr
 td3/td
 td4/td
   /tr
 /tbody
/table
8--

Converting with the following command:
 pandoc -f html -t html input.html  output.html

This resulted in the following HTML output:

--8
table
colgroup
col width=50% /
col width=50% /
/colgroup
tbody
tr class=odd
td align=left1
2/td
td align=left3
4/td
/tr
/tbody
/table
8--

So the td's inside the rows got merged together, and the 2 rows got combined
into one. The upstream changelog for 1.13 mentions a fix for a bug [2] which
looks like the issue I noticed (it also mentions a fix for a bug [3] which
should fix Debian bug #739448, btw.).

Kind regards
Manfred

[1] http://johnmacfarlane.net/pandoc/releases.html
[2] https://github.com/jgm/pandoc/issues/1341
[3] https://github.com/jgm/pandoc/issues/1167

-- System Information:
Debian Release: 8.0
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages pandoc depends on:
ii  libc62.19-13
ii  libffi6  3.1-2+b2
ii  libgmp10 2:6.0.0+dfsg-6
ii  libicu52 52.1-6
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3
ii  libyaml-0-2  0.1.6-3
ii  pandoc-data  1.12.4.2~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  etoolbox   none
pn  pandoc-citeprocnone
ii  texlive-latex-recommended  2014.20141024-2
pn  texlive-luatex none
pn  texlive-xetex  none

-- no debconf information




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762131: pandoc: markdown → docx → markdown roundtrip fails with Data.Text.Encoding.Fusion.streamUtf8: Invalid UTF-8 stream

[John MacFarlane]

pandoc 1.12.4 does not support docx as an input format -- only
as an output format. docx as input is only supported in pandoc 1.13.x.
So, this is not a bug.

+++ Daniel Kahn Gillmor [Sep 18 14 15:31 ]:

Package: pandoc
Version: 1.12.4.2~dfsg-1+b11
Severity: normal

I tried to route the simplest possible markdown document through a
docx roundtrip, and got a failure:

0 dkg@alice:~$ echo 'test document'  test.mdwn
0 dkg@alice:~$ pandoc -o test.docx test.mdwn
0 dkg@alice:~$ pandoc -o test.clean.mdwn test.docx
pandoc: Cannot decode byte '\x9b': Data.Text.Encoding.Fusion.streamUtf8: 
Invalid UTF-8 stream
1 dkg@alice:~$

Thanks for packaging pandoc for debian!

Regards,

   --dkg

-- System Information:
Debian Release: jessie/sid
 APT prefers testing
 APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pandoc depends on:
ii  libc62.19-10
ii  libffi6  3.1-2
ii  libgmp10 2:6.0.0+dfsg-6
ii  libicu52 52.1-5
ii  liblua5.1-0  5.1.5-7
ii  libpcre3 1:8.35-3
ii  libyaml-0-2  0.1.6-2
ii  pandoc-data  1.12.4.2~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  etoolbox   none
pn  pandoc-citeprocnone
ii  texlive-latex-recommended  2014.20140821-1
pn  texlive-luatex none
pn  texlive-xetex  none

-- debconf-show failed




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

Update:  It seems that pcre-light is no longer being actively maintained
upstream.  pcre-regex-builtin is not in Debian.  I thought the solution
might be to add an option to highlighting-kate to use the regex-pcre library
(in debian as libghc-regex-pcre-dev).  However, this seems to have the same
problem:

Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 Left e - compile (compUTF8 + 
compAnchored) 0 (fromString [\\o{0370}-\\o{0377})
Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 e
(11,range out of order in character class)

Is the problem perhaps that the underlying C library pcre has not been
compiled with UTF8 support?

+++ John MacFarlane [Jul 18 14 16:53 ]:

I'd tested before with pcre-regex-builtin, which worked.
I recompiled with pcre-light, and got the failure you report.

The problem can be exhibited in pcre-light:

Prelude Text.Regex.PCRE.Light Data.ByteString.UTF8 match (compile
(fromString
[\\o{0370}-\\o{0377}) [utf8,anchored]) (fromString hi) []
*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of order
in
character class

The unicode ranges seem to be confusing it, even with 'utf8' set.

Submitted an issue upstream:
https://github.com/Daniel-Diaz/pcre-light/issues/1

In the mean time, I suggest that debian packagers use pcre-regex-builtin
instead (though perhaps there was a reason for using pcre-light?).

+++ Samuel Hym [Jul 01 14 18:06 ]:

Hi John,


Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?


I rechecked, using the same version of the package but on a 
different machine, different arch, just in case. But still with 
debian-built packages, and with the same result.


Here is what ghci has to say, with the full versions of the modules used:

GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m +Text.Highlighting.Kate
Prelude Text.Highlighting.Kate highlightAs ocaml a
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package blaze-markup-0.5.1.6 ... linking ... done.
Loading package blaze-html-0.6.1.2 ... linking ... done.
Loading package pcre-light-0.4 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package highlighting-kate-0.5.8.2 ... linking ... done.
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of 
order in character class


You think something else might be to blame in the module stack?
Do you know if there is a way to ask pcre-light to be somewhat more 
informative about the regex producing the issue?


By the way, many thanks for pandoc!

Best regards
Samuel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

Another solution would be to modify the highlighting-kate code to
avoid using character classes with octal escapes.  (I could simulate
them by just listing all the characters.)  Perhaps that is the best
short-term solution.

+++ John MacFarlane [Jul 19 14 08:14 ]:

Update:  It seems that pcre-light is no longer being actively maintained
upstream.  pcre-regex-builtin is not in Debian.  I thought the solution
might be to add an option to highlighting-kate to use the regex-pcre library
(in debian as libghc-regex-pcre-dev).  However, this seems to have the same
problem:

Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 Left e - compile (compUTF8 + 
compAnchored) 0 (fromString [\\o{0370}-\\o{0377})
Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 e
(11,range out of order in character class)

Is the problem perhaps that the underlying C library pcre has not been
compiled with UTF8 support?

+++ John MacFarlane [Jul 18 14 16:53 ]:

I'd tested before with pcre-regex-builtin, which worked.
I recompiled with pcre-light, and got the failure you report.

The problem can be exhibited in pcre-light:

Prelude Text.Regex.PCRE.Light Data.ByteString.UTF8 match (compile
(fromString
[\\o{0370}-\\o{0377}) [utf8,anchored]) (fromString hi) []
*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of order
in
character class

The unicode ranges seem to be confusing it, even with 'utf8' set.

Submitted an issue upstream:
https://github.com/Daniel-Diaz/pcre-light/issues/1

In the mean time, I suggest that debian packagers use pcre-regex-builtin
instead (though perhaps there was a reason for using pcre-light?).

+++ Samuel Hym [Jul 01 14 18:06 ]:

Hi John,


Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?


I rechecked, using the same version of the package but on a 
different machine, different arch, just in case. But still with 
debian-built packages, and with the same result.


Here is what ghci has to say, with the full versions of the modules used:

GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m +Text.Highlighting.Kate
Prelude Text.Highlighting.Kate highlightAs ocaml a
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package blaze-markup-0.5.1.6 ... linking ... done.
Loading package blaze-html-0.6.1.2 ... linking ... done.
Loading package pcre-light-0.4 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package highlighting-kate-0.5.8.2 ... linking ... done.
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range out 
of order in character class


You think something else might be to blame in the module stack?
Do you know if there is a way to ask pcre-light to be somewhat 
more informative about the regex producing the issue?


By the way, many thanks for pandoc!

Best regards
Samuel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

OK, I have the solution!  The \o{377} format for specifying
octal escapes is only supported starting in PCRE 8.34, and debian
has an older version.  \377 can still be used.  So I can adjust
highlighting-kate code to use e.g. \377, as long as we don't have
characters greater than octal 377.

+++ John MacFarlane [Jul 19 14 08:17 ]:

Another solution would be to modify the highlighting-kate code to
avoid using character classes with octal escapes.  (I could simulate
them by just listing all the characters.)  Perhaps that is the best
short-term solution.

+++ John MacFarlane [Jul 19 14 08:14 ]:

Update:  It seems that pcre-light is no longer being actively maintained
upstream.  pcre-regex-builtin is not in Debian.  I thought the solution
might be to add an option to highlighting-kate to use the regex-pcre library
(in debian as libghc-regex-pcre-dev).  However, this seems to have the same
problem:

Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 Left e - compile (compUTF8 + 
compAnchored) 0 (fromString [\\o{0370}-\\o{0377})
Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 e
(11,range out of order in character class)

Is the problem perhaps that the underlying C library pcre has not been
compiled with UTF8 support?

+++ John MacFarlane [Jul 18 14 16:53 ]:

I'd tested before with pcre-regex-builtin, which worked.
I recompiled with pcre-light, and got the failure you report.

The problem can be exhibited in pcre-light:

Prelude Text.Regex.PCRE.Light Data.ByteString.UTF8 match (compile
(fromString
[\\o{0370}-\\o{0377}) [utf8,anchored]) (fromString hi) []
*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of order
in
character class

The unicode ranges seem to be confusing it, even with 'utf8' set.

Submitted an issue upstream:
https://github.com/Daniel-Diaz/pcre-light/issues/1

In the mean time, I suggest that debian packagers use pcre-regex-builtin
instead (though perhaps there was a reason for using pcre-light?).

+++ Samuel Hym [Jul 01 14 18:06 ]:

Hi John,


Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?


I rechecked, using the same version of the package but on a 
different machine, different arch, just in case. But still with 
debian-built packages, and with the same result.


Here is what ghci has to say, with the full versions of the modules used:

GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m +Text.Highlighting.Kate
Prelude Text.Highlighting.Kate highlightAs ocaml a
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package blaze-markup-0.5.1.6 ... linking ... done.
Loading package blaze-html-0.6.1.2 ... linking ... done.
Loading package pcre-light-0.4 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package highlighting-kate-0.5.8.2 ... linking ... done.
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range 
out of order in character class


You think something else might be to blame in the module stack?
Do you know if there is a way to ask pcre-light to be somewhat 
more informative about the regex producing the issue?


By the way, many thanks for pandoc!

Best regards
Samuel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

Upgrading to highlighting-kate 0.5.8.5
https://hackage.haskell.org/package/highlighting-kate
will fix the problem.

+++ John MacFarlane [Jul 19 14 09:19 ]:

OK, I have the solution!  The \o{377} format for specifying
octal escapes is only supported starting in PCRE 8.34, and debian
has an older version.  \377 can still be used.  So I can adjust
highlighting-kate code to use e.g. \377, as long as we don't have
characters greater than octal 377.

+++ John MacFarlane [Jul 19 14 08:17 ]:

Another solution would be to modify the highlighting-kate code to
avoid using character classes with octal escapes.  (I could simulate
them by just listing all the characters.)  Perhaps that is the best
short-term solution.

+++ John MacFarlane [Jul 19 14 08:14 ]:

Update:  It seems that pcre-light is no longer being actively maintained
upstream.  pcre-regex-builtin is not in Debian.  I thought the solution
might be to add an option to highlighting-kate to use the regex-pcre library
(in debian as libghc-regex-pcre-dev).  However, this seems to have the same
problem:

Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 Left e - compile (compUTF8 + 
compAnchored) 0 (fromString [\\o{0370}-\\o{0377})
Prelude Text.Regex.PCRE.ByteString Data.ByteString.UTF8 e
(11,range out of order in character class)

Is the problem perhaps that the underlying C library pcre has not been
compiled with UTF8 support?

+++ John MacFarlane [Jul 18 14 16:53 ]:

I'd tested before with pcre-regex-builtin, which worked.
I recompiled with pcre-light, and got the failure you report.

The problem can be exhibited in pcre-light:

Prelude Text.Regex.PCRE.Light Data.ByteString.UTF8 match (compile
(fromString
[\\o{0370}-\\o{0377}) [utf8,anchored]) (fromString hi) []
*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of order
in
character class

The unicode ranges seem to be confusing it, even with 'utf8' set.

Submitted an issue upstream:
https://github.com/Daniel-Diaz/pcre-light/issues/1

In the mean time, I suggest that debian packagers use pcre-regex-builtin
instead (though perhaps there was a reason for using pcre-light?).

+++ Samuel Hym [Jul 01 14 18:06 ]:

Hi John,


Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?


I rechecked, using the same version of the package but on a 
different machine, different arch, just in case. But still 
with debian-built packages, and with the same result.


Here is what ghci has to say, with the full versions of the modules used:

GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m +Text.Highlighting.Kate
Prelude Text.Highlighting.Kate highlightAs ocaml a
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package blaze-markup-0.5.1.6 ... linking ... done.
Loading package blaze-html-0.6.1.2 ... linking ... done.
Loading package pcre-light-0.4 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package highlighting-kate-0.5.8.2 ... linking ... done.
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range 
out of order in character class


You think something else might be to blame in the module stack?
Do you know if there is a way to ask pcre-light to be somewhat 
more informative about the regex producing the issue?


By the way, many thanks for pandoc!

Best regards
Samuel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

I'd tested before with pcre-regex-builtin, which worked.
I recompiled with pcre-light, and got the failure you report.

The problem can be exhibited in pcre-light:

Prelude Text.Regex.PCRE.Light Data.ByteString.UTF8 match (compile
(fromString
[\\o{0370}-\\o{0377}) [utf8,anchored]) (fromString hi) []
*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of order
in
character class

The unicode ranges seem to be confusing it, even with 'utf8' set.

Submitted an issue upstream:
https://github.com/Daniel-Diaz/pcre-light/issues/1

In the mean time, I suggest that debian packagers use pcre-regex-builtin
instead (though perhaps there was a reason for using pcre-light?).

+++ Samuel Hym [Jul 01 14 18:06 ]:

Hi John,


Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?


I rechecked, using the same version of the package but on a different 
machine, different arch, just in case. But still with debian-built 
packages, and with the same result.


Here is what ghci has to say, with the full versions of the modules used:

GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude :m +Text.Highlighting.Kate
Prelude Text.Highlighting.Kate highlightAs ocaml a
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package blaze-markup-0.5.1.6 ... linking ... done.
Loading package blaze-html-0.6.1.2 ... linking ... done.
Loading package pcre-light-0.4 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package highlighting-kate-0.5.8.2 ... linking ... done.
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of 
order in character class


You think something else might be to blame in the module stack?
Do you know if there is a way to ask pcre-light to be somewhat more 
informative about the regex producing the issue?


By the way, many thanks for pandoc!

Best regards
Samuel



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753299: libghc-highlighting-kate-dev: Highlighting Ocaml fails

[John MacFarlane]

This is puzzling.  This problem was fixed upstream in highlighting-kate
0.5.8.1.  (See the changelog.) 0.5.8.2 fixes a similar problem with
perl.  I cannot reproduce what you're seeing with my locally installed
version (not installed through debian).

Are you certain that the version you are using in GHCI is 0.5.8.2,
and not an older version (perhaps from your user database)?

+++ Samuel Hym [Jun 30 14 12:35 ]:

Package: libghc-highlighting-kate-dev
Version: 0.5.8.2-1
Severity: important

Dear Maintainer,

Highlighting fails on ocaml code with a regex error.

I tried to highlight the most simple code possible in ghci:

Prelude Text.Highlighting.Kate highlightAs ocaml a
[*** Exception: Text.Regex.PCRE.Light: Error in regex: range out of
order in character class

This affects pandoc/1.12.4.2~dfsg-1+b1 while
pandoc/1.12.3.3~dfsg-1+b11 works.

Best regards,
Samuel


-- System Information:
Debian Release: jessie/sid
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libghc-highlighting-kate-dev depends on:
ii  ghc [libghc-containers-dev-0.5.0.0-ab1da]7.6.3-13
ii  libc62.19-4
pn  libghc-base-dev-4.6.0.1-8aa5dnone
ii  libghc-blaze-html-dev [libghc-blaze-html-dev-0.6.1.2-0108a]  0.6.1.2-1+b2
ii  libghc-mtl-dev [libghc-mtl-dev-2.1.2-94c72]  2.1.2-4
ii  libghc-parsec3-dev [libghc-parsec-dev-3.1.3-6c6e2]   3.1.3-3+b1
ii  libghc-pcre-light-dev [libghc-pcre-light-dev-0.4-f5309]  0.4-6
ii  libghc-utf8-string-dev [libghc-utf8-string-dev-0.3.7-26a8e]  0.3.7-3

libghc-highlighting-kate-dev recommends no packages.

Versions of packages libghc-highlighting-kate-dev suggests:
ii  libghc-highlighting-kate-doc   0.5.8.2-1
pn  libghc-highlighting-kate-prof  none

-- no debconf information




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749891: pandoc: doesn't support some Unicode characters with PDF output

[John MacFarlane]

+++ Vincent Lefevre [May 30 14 14:37 ]:

Package: pandoc
Version: 1.12.3.3~dfsg-1+b11
Severity: normal

$ cat file
a ≤ b
$ pandoc file -o out.pdf
pandoc: Error producing PDF from TeX source.
! Package inputenc Error: Unicode char \u8:≤ not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H return  for immediate help.
...

l.50 a ≤

Try running pandoc with --latex-engine=xelatex.



If I try with --latex-engine=xelatex, I no longer get an error, but
the ≤ character doesn't appear. There are similar problems with
other characters. See e.g. Markus Kuhn's UTF-8-demo.txt from:

 http://www.cl.cam.ac.uk/~mgk25/ucs/examples/


Most likely this is because you're using a font that doesn't have
these glyphs.  Try with

   -V mainfont=FONT NAME

where FONT NAME is a (ttf) font you have installed that has the
character in question.

As far as I can see, this is not a pandoc bug.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742954: pandoc: Does not respect the http_proxy environment variable

[John MacFarlane]

Upstream maintainer here.  Yes, it would be terrific if you'd
report this upstream, at
http://github.com/jgm/pandoc/issues

By default, pandoc now uses http-conduit to connect (since this,
unlike HTTP, supports SSL).  http-conduit has a way to specify a
proxy, but it may not automatically support that environment
variable.  This could be done in pandoc.

+++ intrig...@debian.org [Mar 29 14 11:54 ]:

Package: pandoc
Version: 1.12.3.3~dfsg-1
Severity: normal

Hi,

I'm running:

   $ export http_proxy=http://127.0.0.1:3142/
   $ pandoc --self-contained -t revealjs -s slides.mdwn -o slides.html

... and pandoc connects directly to the web, while I would expect it
to respect the configured http_proxy.

This is a bit surprising to me, as pandoc uses haskell-http, that has
support for this environment variable. Maybe pandoc needs to
explicitly enable haskell-http's proxy support?

If you prefer me to report this problem upstream, just tell me :)

-- System Information:
Debian Release: jessie/sid
 APT prefers unstable
 APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pandoc depends on:
ii  libc62.18-4
ii  libffi6  3.1~rc1-2
ii  libgmp10 2:6.0.0+dfsg-1
ii  libicu52 52.1-3
ii  liblua5.1-0  5.1.5-5
ii  libpcre3 1:8.31-2
ii  libyaml-0-2  0.1.4-3.1
ii  pandoc-data  1.12.3.3~dfsg-1
ii  zlib1g   1:1.2.8.dfsg-1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  etoolbox   none
pn  pandoc-citeprocnone
ii  texlive-latex-recommended  2013.20140314-1
ii  texlive-luatex 2013.20140314-1
ii  texlive-xetex  2013.20140314-1

-- no debconf information

--
 intrigeri
 | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
 | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739448: pandoc: endless loop converting from html

[John MacFarlane]

+++ Jonas Smedegaard [Feb 19 14 21:41 ]:
 reopen 739448
 thanks
 
 Quoting Thomas Viehweger (2014-02-19 20:49:51)
  pandoc -f html -t epub -o 131212.epub \
  http://lwn.net/Articles/575838/bigpage?format=printable
 
  I can reproduce the error.
 
  Seems it is not tied to epub (trying with markdown does the same) 
  but instead with impurity of html (it works after cleaning up with 
  tidy).
 
  Investigating closer - using weblint (Debian package weblint-perl) 
  reveals that the html page is broken: contains several non-closed tr 
  and td tags.
 
  thanks for the quick response. tidy-ing the html file really helps.
 
  But.. the previous version of pandoc in testing (1.9.?) also behaves 
  as expected (no endless loop).
 
  In my opinion pandoc should not go into an endless loop - no matter 
  what I feed it with.
  It might produce garbage or abort. But an endless loop is not 
  acceptable (for me).
 
 Good point.  Reopening the bugreport.
 
 Btw: A closed bugreport can still be posted to (I guess that's why you 
 contacted me discretely, and I took the liberty to reply in public).  
 Only when _archived_ can you no longer post to it.

I've added a bug report upstream:
https://github.com/jgm/pandoc/issues/1167


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724636: [Pkg-haskell-maintainers] Bug#724636: Could you please keep us posted on pandoc 1.12?

[John MacFarlane]

Jonas,

I plan to put out a new pandoc release in the next couple weeks.  I'd be
happy to fix any issues that are causing problems for Debian packaging.
Just explain to me clearly what those issues are (e.g. which javascript
code you're talking about).

Best,
John

+++ Jonas Smedegaard [Dec 19 13 15:28 ]:
 Hi Martin,
 
 Quoting Martin Quinson (2013-12-09 16:00:33)
  I would like to know if you had the opportunity to work on the 
  packaging of pandoc 1.12, please? I would love to help if I can (but I 
  don't know anything of pandoc myself, I just happen to need it).
 
 Thanks for the interest and kind offer!
 
 The core issue is that Pandoc lacks (non-minified) source for included 
 Javascript code.
 
 Newer upstream release has improvements related to this, but 
 unfortunately needs more work to satisfy Debian Policy: Some javascript 
 code is no longer shipped with Pandoc source. Unfortunately some 
 Javascript code remains, and also the dropped coe is then instead 
 fetched at runtime which arguably don't pass the lonely island test.
 
 As I see it, the proper solution is therefore to a) package all needed 
 Javascript code as independent libjs-* packages and b) work with 
 upstream on favoring local code (if available) over online CDN fetching.
 
 Alternatively - but IMO too crude - would be to package the newer 
 upstream release, with remaining Javascript code stripped, and adding a 
 README.Debian note that corresponding output formats are broken.
 
 
 I believe some of above should be possible to help with even without 
 understanding to code or the packaging, e.g. discussing this with 
 upstream author - if he haven't already heard it now, as I think he's 
 tracking these bugreports :-)
 
 
  - Jonas
 
 -- 
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 
  [x] quote me freely  [ ] ask before reusing  [ ] keep private


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724636: Could you please keep us posted on pandoc 1.12?

[John MacFarlane]

PS.  Starting with 1.12, the citation processing functionality
of pandoc has been split into a separate executable and library,
pandoc-citeproc.  So that ought to be debianized too.  The package
provides both a library and an executable, and it has associated
data files.

pandoc-citeproc should be a 'Suggests' for pandoc.

I will be releasing a new version of this, too, in the next couple
weeks, and it would make sense to wait til after that release.

See also https://github.com/jgm/pandoc-citeproc/issues/6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#723022: [Pkg-haskell-maintainers] Bug#723022: [pandoc] package split with only Recommends: causes FTBFS on other packages

[John MacFarlane]

+++ Jonas Smedegaard [Sep 15 13 16:30 ]:
 Quoting Timo Weingärtner (2013-09-15 15:39:11)
  pandoc only Recommends: pandoc-data, so packages Build-Depending on 
  pandoc for e.g. manpage generation will FTBFS.
  
  Please change the Recommends: into a Depends:
 
 Pandoc is usable without those datafiles, for some special uses.
 
 I believe the proper thing to do is for such packages to build-depend 
 also on pandoc-data.

For what it's worth (from a non Debian insider), I think pandoc should depend
on pandoc-data.

Without pandoc-data, many invocations of pandoc will fail -- including
any use of the --standalone (-s) option, and any attempt to produce a
docx, epub, or odt.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721417: Compressed JavaScript libraries

[John MacFarlane]

Note that upstream has already substituted an uncompressed version
(this will be in the forthcoming 1.12 release).

+++ Luca Falavigna [Aug 31 13 13:20 ]:
 Source: pandoc
 Version: 1.9.4.2-2
 Severity: serious
 Tags: sid jessie
 
 
 Source ships a couple of compressed JavaScript libraries without
 corresponding uncompressed versions:
  * data/LaTeXMathML.js
  * data/slidy/scripts/slidy.js.gz
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697306: Versioning problem with templates in pandoc binary

[John MacFarlane]

+++ Joachim Breitner [Jan 03 13 21:01 ]:
 Package: pandoc
 Version: 1.9.4.5-2
 Severity: normal
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi,
 
 currently, the templates are shipped in the pandoc binary package, in a
 path that contains the version number. Now if a program (or source
 package, like xmonad) needs both the pandoc library _and_ the pandoc
 templates, if it depends on libghc-pandoc-dev, pandoc, it may happen
 that these come from different versions and a program built against the
 former fails to find working templates.
 
 This occurred in the xmonad build in experimental, where
 libghc-pandoc-dev came from experimental and pandoc from unstable.
 
 A solution could be a libghc-pandoc-data package that contains the data
 files, i.e. the templates. libghc-pandoc-dev would then depend on a
 compatible version of libghc-pandoc-data. Every package that includes a
 program built with libghc-pandoc-dev (including the pandoc binary
 package itself) copies this dependency.
 
 This is how it is done in libghc-citeproc; there is some automation
 available there, please check it out for inspiration and copy’n’pasting.
 
 Greetings,
 Joachim

One note on this:  the templates are not the only data files pandoc
uses.  There are also reference.docx, reference.odt, default.csl,
and files for slides and LaTeXMathML.  See the data-files stanza
of pandoc.cabal for a complete list.

In the development version of pandoc, I've simplified things a bit
by putting all data files in the data/ subdirectory.   That is how
it will be in the next release.

John


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611328: Acknowledgement (Can not parse title and sub-title from reStructuredText-file)

[John MacFarlane]

This bug was fixed in pandoc 1.8, as noted in the changelog.

+++ Juhapekka Tolvanen [Jan 28 11 07:27 ]:
 
 I forgot to mention that this bug affect all kind of output pandoc
 spits out. For example ODT-file looks like this in OpenOffice.org:
 
  Clip here 
  Läsnäolon voima -kirjan harjoitukset
 
  Clip here 
 
 And it is written in main font, not title font.
 
 
 -- 
 Juhapekka naula Tolvanen * http colon slash slash iki dot fi slash juhtolv
 Quidquid Latine dictum sit altum videtur.
 
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660463: pandoc: fails to highlight code in html output

[John MacFarlane]

This bug has been fixed for a long time.

+++ Markus Glötzel [Feb 19 12 13:37 ]:
 Package: pandoc
 Version: 1.5.1.1-5+b1
 Severity: normal
 
 Pandoc uses short classes for syntax highlighting (like 'class=kw') in the 
 body of the generated html document, but there are no matching selectors in 
 the css in the document's head. Therefore, there is no syntax highlighting in 
 the rendered document. See 
 http://groups.google.com/group/pandoc-discuss/browse_thread/thread/7d7d4608b8fe7031
  for a longer description. 
 
 -- System Information:
 Debian Release: 6.0.4
   APT prefers stable
   APT policy: (950, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.2.0-0.bpo.1-686-pae (SMP w/1 CPU core)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages pandoc depends on:
 ii  libc6   2.11.3-2 Embedded GNU C Library: Shared 
 lib
 ii  libffi5 3.0.9-3  Foreign Function Interface 
 library
 ii  libgmp3c2   2:4.3.2+dfsg-1   Multiprecision arithmetic library
 ii  libpcre38.02-1.1 Perl 5 Compatible Regular 
 Expressi
 ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime
 
 pandoc recommends no packages.
 
 Versions of packages pandoc suggests:
 ii  texlive-latex-extra   2009-10TeX Live: LaTeX supplementary 
 pack
 ii  texlive-latex-recommended 2009-11TeX Live: LaTeX recommended 
 packag
 ii  texlive-xetex 2009-11TeX Live: XeTeX packages
 
 -- no debconf information
 
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#667816: Charset written in a wrong way, when generating texinfo-file

[John MacFarlane]

+++ Juhapekka Tolvanen [Apr 06 12 22:36 ]:
 Package: pandoc
 Version: 1.9.1.1-1
 Severity: important
 
 
 When pandoc creates texinfo-file, it starts like this:
 
  Clip here 
 \input texinfo
 @documentencoding utf-8
  Clip here 
 
 That causes bug #646914:
 
  Clip here 
 
 Well, notice that you use:
 
 ,
 | @documentencoding utf-8
 `
 
 but the Texinfo manual says to use:
 
 ,
 | @documentencoding UTF-8
 `
 
  Clip here 
 
 
 
 
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'testing-proposed-updates'), (500, 
 'stable-updates'), (500, 'proposed-updates'), (102, 'testing'), (101, 
 'unstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
 Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages pandoc depends on:
 ii  libbibutils2  4.12-5
 ii  libc6 2.13-27
 ii  libffi5   3.0.10-3
 ii  libgmp10  2:5.0.4+dfsg-1
 ii  libpcre3  1:8.30-4
 ii  zlib1g1:1.2.6.dfsg-2
 
 pandoc recommends no packages.
 
 Versions of packages pandoc suggests:
 ii  texlive-latex-recommended  2011.20120322-2
 ii  texlive-luatex 2011.20120322-2
 ii  texlive-xetex  2011.20120322-2
 
 -- no debconf information
 
 -- 

This bug was fixed in pandoc 1.9.3, as noted in the changelog.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#682433: pandoc: FTBFS[mips* sparc s390x]: threading detection broken

[John MacFarlane]

+++ Christoph Egger [Jul 22 12 19:31 ]:
 Package: src:pandoc
 Version: 1.9.4.2-1
 Severity: serious
 Tags: sid wheezy patch
 Justification: fails to build from source (but built successfully in the past)
 
 Hi!
 
 Your package failed to build on the buildds:
 
 Linking dist-ghc/build/pandoc/pandoc ...
 /usr/bin/ld: cannot find -lHSrts_thr
 collect2: ld returned 1 exit status
 
 Full build log at
 https://buildd.debian.org/status/fetch.php?pkg=pandocarch=mipsver=1.9.4.2-1stamp=1341543393
 
 Patch attached
 
 Regards
 
 Christoph
 

 From 48dae8e98b4a946c5479dc6e46226c8d7006a7cb Mon Sep 17 00:00:00 2001
 From: Christoph Egger christ...@debian.org
 Date: Sun, 22 Jul 2012 19:27:51 +0200
 Subject: [PATCH] Enable threaded only on threaded systems
 
 Up until now threading was enabled if there is no threading library at
 an obsolete location which obviously is always true. Now check where
 the threading libs are supposed to be and enable threaded build in
 case threading is available (and not absent)
 ---
  debian/rules |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/debian/rules b/debian/rules
 index cc0523a..494dd8d 100755
 --- a/debian/rules
 +++ b/debian/rules
 @@ -18,7 +18,7 @@ DEB_INSTALL_MANPAGES_pandoc = man/man1/*.1 man/man5/*.5 
 debian/hsmarkdown.1
  DEB_SETUP_GHC6_CONFIGURE_ARGS = -fhighlighting
  
  # Use threaded RTS only when supported
 -DEB_SETUP_GHC6_CONFIGURE_ARGS += $(if $(wildcard 
 /usr/lib/ghc-$(GHC6_VERSION)/libHSrts_thr.a),,--flags=-threaded)
 +DEB_SETUP_GHC6_CONFIGURE_ARGS += $(if $(wildcard 
 /usr/lib/ghc/libHSrts_thr.a),--flags=-threaded,)
  
  # Disable timer to help build on slow arches like hppa
  DEB_SETUP_GHC6_CONFIGURE_ARGS += --ghc-options=+RTS -V0 -RTS
 -- 

Note:  Upstream has already removed the '-threaded' flag from
pandoc.cabal, so an alternative approach would be to patch
pandoc.cabal.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#662210: [highlighting-kate] Css not completely uppercase in extended descriptions

[John MacFarlane]

+++ Filipus Klutiero [Mar 04 12 13:22 ]:
 Source: highlighting-kate
 Version: 0.5.0.5-1
 Severity: minor
 
 The extended descriptions contain:
 
 Currently the following languages are supported: Ada, Asp, Awk,
 Bash, Bibtex, C, Cmake, Coldfusion, Commonlisp, Cpp, Css, D,
 Djangotemplate, Doxygen, Dtd, Eiffel, Erlang, Fortran, Haskell,
 Html, Java, Javadoc, Javascript, Json, Latex, Lex,
 LiterateHaskell, Lua, Makefile, Matlab, Mediawiki, Modula3, Nasm,
 Objectivec, Ocaml, Pascal, Perl, PHP, Postscript, Prolog, Python,
 Rhtml, Ruby, Scala, Scheme, Sgml, SQL, MySQL, PostgreSQL, Tcl,
 Texinfo, Xml, Xslt, Yacc.
 
 CSS is an acronym and should be completely uppercase.
 
 By the way, XSLT (Extensible Stylesheet Language Transformations)
 should also be completely uppercase.

Note also:  This list of supported languages is out of date.
The README says:

Currently, the following languages/formats are supported:

- Actionscript
- Ada
- Apache
- Asn1
- Asp
- Awk
- Bash
- Bibtex
- Boo
- C
- Changelog
- Clojure
- Cmake
- Coffeescript
- Coldfusion
- Commonlisp
- Cpp
- Cs
- Css
- D
- Diff
- Djangotemplate
- Doxygen
- Dtd
- Eiffel
- Email
- Erlang
- Fortran
- Fsharp
- Gnuassembler
- Go
- Haskell
- Haxe
- Html
- Ilerpg
- Ini
- Java
- Javadoc
- Javascript
- Json
- Jsp
- Latex
- Lex
- LiterateHaskell
- Lua
- Makefile
- Mandoc
- Matlab
- Maxima
- Mediawiki
- Metafont
- Mips
- Modula2
- Modula3
- Monobasic
- Nasm
- Noweb
- Objectivec
- Objectivecpp
- Ocaml
- Octave
- Pascal
- Perl
- Php
- Pike
- Postscript
- Prolog
- Python
- R
- Relaxngcompact
- Rhtml
- Ruby
- Scala
- Scheme
- Sci
- Sed
- Sgml
- Sql
- SqlMysql
- SqlPostgresql
- Tcl
- Texinfo
- Verilog
- Vhdl
- Xml
- Xorg
- Xslt
- Xul
- Yacc
- Yaml

Some of these need to be all uppercase, some need to be two words, etc.
Since the list of supported languages changes from release to release, it
might be easier to simply delete the paragraph listing the languages
from the Debian description.  That is what I have done in the Cabal file;
see http://hackage.haskell.org/package/highlighting-kate-0.5.0.5





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631844: s5 output produces invalid xhtml

[John MacFarlane]

This is fixed in pandoc 1.8.2 and later versions.

+++ Clint Adams [Jun 27 11 17:26 ]:
 Package: pandoc
 Version: 1.8.1.1-1
 
 When using --offline and producing s5 output, pandoc generates
 XHTML 1.0 Transitional with inline JavaScript.  This JavaScript
 is not tagged as CDATA and thus XML parsers choke.
 
 To solve this, the inline JavaScript can be encloesd within
 a
 ![CDATA[
 ]]
 
 tag, though the resulting page is still not properly rendered.
 
 
 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646100: Do not create DocBook-XML suitable for xmlto

[John MacFarlane]

+++ Juhapekka Tolvanen [Oct 21 11 12:47 ]:
 Package: pandoc
 Version: 1.8.2.1-2+b2
 Severity: important
 
 
 That XML-file is available here:
 
 http://iki.fi/juhtolv/tolleharj/
 
 juhtolv@juhtolv:/home/juhtolv/seka/Eckhart_Tolle/harjoitukset % tidy -m -xml 
 -utf8 juhtolv_tolle_harjoitukset.xml
 No warnings or errors were found.
 
 
 To learn more about HTML Tidy see http://tidy.sourceforge.net
 Please fill bug reports and queries using the tracker on the Tidy
 web site.
 Additionally, questions can be sent to html-t...@w3.org
 HTML and CSS specifications are available from http://www.w3.org/
 Lobby your company to join W3C, see http://www.w3.org/Consortium
 
 juhtolv@juhtolv:/home/juhtolv/seka/Eckhart_Tolle/harjoitukset % xmlto -vv man 
 juhtolv_tolle_harjoitukset.xml 
 Source format: docbook / root element: nodes: 
 Format script: /usr/share/xmlto/format/docbook/man
 Convert to troff
 Real stylesheet:
 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
 /usr/bin/xmllint --noout --nonet --xinclude --postvalid --noent
 /home/juhtolv/seka/Eckhart_Tolle/harjoitukset/juhtolv_tolle_harjoitukset.xml
 Stylesheet: /tmp/xmlto-xsl.CcGAAv
 /usr/bin/xsltproc   --nonet --xinclude \
  -o /tmp/xmlto.rBtMnG/juhtolv_tolle_harjoitukset.proc \
  /tmp/xmlto-xsl.CcGAAv \
  
 /home/juhtolv/seka/Eckhart_Tolle/harjoitukset/juhtolv_tolle_harjoitukset.xml
 Erro:  no refentry: No refentry elements found in Läsnäolon voim
 Läsnäolon voima -kirjan harjoitukset: Eräänlaiset muistiinpanot
 [1]1647 exit 1 xmlto -vv man juhtolv_tolle_harjoitukset.xml

I don't consider this a bug.

'xmlto html' and 'xmlto pdf' work fine for this input. 'xmlto man' apparently
expects a certain kind of docbook file -- one whose main node is 'refentry'.
http://docbook.org/tdg/en/html/refentry.html

Pandoc could only know to produce such a file if it knew ahead of time what
you planned to do with the docbook file you were generating, and of course it
can't know that.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640645: newer upstream version

[John MacFarlane]

+++ Clint Adams [Sep 06 11 15:21 ]:
 On Tue, Sep 06, 2011 at 05:19:04PM +0200, Jonas Smedegaard wrote:
  Where?  I do not see it at 
  http://code.google.com/p/pandoc/downloads/list
 
 Hmm, strange.  It's at
 
 http://hackage.haskell.org/packages/archive/pandoc/1.8.2.1/

Upstream maintainer here.  This was a very minor release, mainly to
relax some version bounds, and I guess I forgot to upload to the
googlecode downloads site.  I've now done that.

John



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#610583: Quick workaround.

[John MacFarlane]

+++ Adam Buchbinder [Mar 24 11 17:02 ]:
 Download epub.css from here:
 
 https://github.com/jgm/pandoc/raw/master/epub.css
 
 Then just add '--epub-stylesheet epub.css' to your command line
 (assuming epub.css is in the current direstory), and it should work
 properly.
 
 John, I'm not sure what you mean about blanks at the beginning of the
 document--epub output will fail regardless of the input if it can't find
 epub.css. I'm pretty sure this is just a packaging problem, and an
 easily worked-around one at that.

Yes, it's a simple packaging problem.  epub.css needs to be installed
in the pandoc data directory (the same directory where reference.odt
goes).

John



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#610583: This bug disturbs me, too!

[John MacFarlane]

+++ Jonas Smedegaard [Jan 28 11 11:18 ]:
 On Fri, Jan 28, 2011 at 07:55:22AM +0200, Juhapekka Tolvanen wrote:
 This bug disturbs me, too! So, please fix it ASAP!
 
 Please beware that your tone is rather rude.
 
 You are not my boss, please do not give me orders, but talk to me
 nicely.  Same goes for all other bugreports your interact with - we
 are all just volunteers.  Your style _discourages_ working on those
 bugs you comment on - and I imagine your intend was the opposite.
 
 
 No, I am not pissed (yet) so no need to apologize. I just want to
 make you aware of how your writing style is seen as hostile from my
 end.

Upstream here.  First, I want to echo Jonas's comments on tone.

Anyway, the problem is the blank line at the beginning
of your document. If you remove that, it will work properly.

pandoc -f rst -t docbook -s

Läsnäolon voima -kirjan harjoitukset


=
Muistiinpanot
=

^D
?xml version=1.0 encoding=utf-8 ?
!DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.4//EN
  http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd;
article
  articleinfo
titleLäsnäolon voima -kirjan harjoitukset: Muistiinpanot/title
  /articleinfo

/article

I will think about changing the parser so it skips blanks at the beginning
of a document.

John



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#600691: libghc6-texmath-dev: should link against libghc6-parsec3-dev

[John MacFarlane]

+++ Jonas Smedegaard [Oct 19 10 12:44 ]:
 On Tue, Oct 19, 2010 at 12:29:47PM +0200, Joachim Breitner wrote:
 Am Dienstag, den 19.10.2010, 11:03 +0200 schrieb Jonas Smedegaard:
 Package: libghc6-texmath-dev
 Version: 0.3.0.2-2+b1
 Severity: important
 
 Hi,
 
 Currently texmath links against parsec2, and highlighting-kate
 against parsec3.
 
 Recent Pandoc needs both and fails to build when linked against
 different versions of parsec, so the wonderful new Pandoc cannot
 be packaged for Debian :-(
 
 Simply bumping libghc6-texmath build-dependency on
 libghc6-parsec3-dev and rebuilding makes the Pandoc build
 succeed.
 
 I thought this would be no problem as long as pandoc does not use
 parsec-types from both texmath and highlighting-kate. Does it do
 that? Did you test building pandoc with cabal (which is more picky
 about such issues) or regular Setup.hs?
 
 Sorry - I don't know the answers to above questions.  Cc'ing John,
 who should know.

I don't know the answer to the question about building. I think a standard
debian-haskell build script is being used, and I assume it uses Setup.hs
directly instead of cabal. But I'm not positive.

Pandoc does use a parser defined in texmath.  So if texmath links
against parsec2, and the rest of pandoc links against parsec3 (as
it currently does in the debian package), there might be a problem
there.

Jonas, have you tried changing the pandoc debian/rules to link against
parsec2?  Pandoc 1.6 should work with either version of parsec.

It seems to me that it would be best if all of these inter-operating
packages linked against the same version of parsec.  All three of
them will currently work with either version.  Would the maintainer
of texmath consider bumping the build dependency to parsec3?

 Do you plan to upload pandoc to unstable or experimental? Is it
 targeted to squeeze?
 
 (But no objections to doing the bump, the question is whether we
 want to do it now in unstable, now in experimental, or after the
 release in unstable)
 
 It is a new upstream release, so unless John can help raise concern
 about security bugs in older releases, I believe it is too late in
 the game for Squeeze.

Unfortunately, I don't see any security fixes in the changelog.

John



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: pandoc FTBFS

[John MacFarlane]

+++ Iain Lane [Mar 12 10 09:23 ]:
 Heya,
 
 On Sat, Feb 27, 2010 at 07:47:03PM +0100, Joachim Breitner wrote:
 Hi,
 [...]
 [...]
 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.
 
 that sounds good. We are not at the point of a transition yet, and
 pandoc is not the only thing waiting, but I’d like to get the TODO list
 smaller if possible. I’ll ask again in one or two weeks if I hear
 nothing :-)
 
 We now are almost at the end of the transition. Yesterday, along
 with Marcot kindly doing uploads, we managed to clear agda and
 magic-haskell from the radar. The release team are now telling us
 that pandoc (along with xmonad-contrib/hppa and
 haskell-src-exts/various FTBFS) is the last big blocker for testing
 transition to start happening again.
 
 Is there any news on the 1.5 release?

Probably, it's going to be at least another week.

I don't want to hold things up, so an alternative would be to provide a
minimal patch for the current version in the debian package. If needed,
I can work on this tonight; Jonas would then need to upload a new
version with the patch.

John




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: pandoc FTBFS

[John MacFarlane]

+++ John MacFarlane [Mar 12 10 09:27 ]:
 +++ Iain Lane [Mar 12 10 09:23 ]:
  Heya,
  
  On Sat, Feb 27, 2010 at 07:47:03PM +0100, Joachim Breitner wrote:
  Hi,
  [...]
  [...]
  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.
  
  that sounds good. We are not at the point of a transition yet, and
  pandoc is not the only thing waiting, but I’d like to get the TODO list
  smaller if possible. I’ll ask again in one or two weeks if I hear
  nothing :-)
  
  We now are almost at the end of the transition. Yesterday, along
  with Marcot kindly doing uploads, we managed to clear agda and
  magic-haskell from the radar. The release team are now telling us
  that pandoc (along with xmonad-contrib/hppa and
  haskell-src-exts/various FTBFS) is the last big blocker for testing
  transition to start happening again.
  
  Is there any news on the 1.5 release?
 
 Probably, it's going to be at least another week.
 
 I don't want to hold things up, so an alternative would be to provide a
 minimal patch for the current version in the debian package. If needed,
 I can work on this tonight; Jonas would then need to upload a new
 version with the patch.

Hold on -- I recall now that there were two issues.  One was the UTF8
issue, which is easily fixed with a small patch. The other is that
pandoc 1.3's use of TH seems to prevent it from compiling on
several architectures.  That can't be fixed with a small patch, but
will be fixed in 1.5. Given this, maybe I should just try to finish 1.5
quickly?

John




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: pandoc FTBFS

[John MacFarlane]

+++ 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




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570964: [Pkg-haskell-maintainers] Bug#570964: FTBFS: hGetContents: invalid argument

[John MacFarlane]

+++ Joachim Breitner [Feb 22 10 15:24 ]:
 Hi,
 
 Am Montag, den 22.02.2010, 15:05 +0100 schrieb Cyril Brulebois:
  Source: highlighting-kate
  your package FTBFS:
  | Running hscolour for highlighting-kate-0.2.5...
  | HsColour: Text/Highlighting/Kate/Syntax/D.hs: hGetContents: invalid 
  argument (invalid UTF-8 byte sequence)
  | make: *** [build-haddock-stamp] Error 1

(Upstream developer here:) I think I see the root of the problem.
highlighting-kate's syntax highlighting modules are generated
programmatically from kate xml language definitions.  I updated
highlighting-kate's own modules for compatibility with GHC 6.12
(where you can't use System.IO.UTF8 or you'll get double
decoding/encoding), but I forgot to update the program that
writes the modules for particular languages. So these source
files are not themselves properly encoded.

I will fix this and upload a new version to HackageDB today if
I can.

John




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#570964: [Pkg-haskell-maintainers] Bug#570964: FTBFS: hGetContents: invalid argument

[John MacFarlane]

+++ John MacFarlane [Feb 22 10 09:14 ]:
 +++ Joachim Breitner [Feb 22 10 15:24 ]:
  Hi,
  
  Am Montag, den 22.02.2010, 15:05 +0100 schrieb Cyril Brulebois:
   Source: highlighting-kate
   your package FTBFS:
   | Running hscolour for highlighting-kate-0.2.5...
   | HsColour: Text/Highlighting/Kate/Syntax/D.hs: hGetContents: invalid 
   argument (invalid UTF-8 byte sequence)
   | make: *** [build-haddock-stamp] Error 1
 
 (Upstream developer here:) I think I see the root of the problem.
 highlighting-kate's syntax highlighting modules are generated
 programmatically from kate xml language definitions.  I updated
 highlighting-kate's own modules for compatibility with GHC 6.12
 (where you can't use System.IO.UTF8 or you'll get double
 decoding/encoding), but I forgot to update the program that
 writes the modules for particular languages. So these source
 files are not themselves properly encoded.

On further investigation:  the source files in the current Hackage
package (0.2.6) do seem to be properly encoded.  (I generated them
on a machine running ghc 6.10.4.)  So I am not sure what the problem
is with the D.hs module...

John




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: pandoc FTBFS

[John MacFarlane]

+++ Joachim Breitner [Feb 22 10 21:21 ]:
 Hi,
 
 
  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.

John




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500662: pandoc: reST comment blocks incorrectly interpreted

[John MacFarlane]

We believe that this issue has been resolved in pandoc 1.3, now
in unstable.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#499865: pandoc: upstream should remove bogus 'debian/' directory from source

[John MacFarlane]

The debian/ directory has been removed from the upstream source.
We believe this bug can be closed now.

+++ Ben Finney [Sep 23 08 14:34 ]:
 Package: pandoc
 Version: 0.46+2
 Severity: minor
 
 The upstream source code (as fetched on 2008-09-23 from 
 URL:http://pandoc.googlecode.com/svn/trunk/) contains a bogus 
 'debian/' directory. That directory should be removed by the upstream 
 developers, leaving only the non-Debian-specific source; instead, it 
 should be added separately as part of the Debian packaging (in the 
 '….diff.gz').
 
 
 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: Fw: Processed: found 559978 in 1.3-1

[John MacFarlane]

+++ Jonas Smedegaard [Dec 15 09 20:11 ]:
 Hi John (and others following this issue),
 
 I dare respond through our BTS rather than privately, as I see
 nothing in need of discretion in your mail and we should generally
 work transparently and in the open whenever possible[1].
 
 I have commented below the quoted text...
 
 On Tue, Dec 15, 2009 at 10:39:22AM -0800, John MacFarlane wrote:
 This is unfortunate.  Pandoc uses template Haskell to splice the
 contents of some data files into source files, so they can be built
 into the executable.  But apparently not all architectures have a
 version of GHC that is capable of handling template Haskell.
 This will keep pandoc 1.3 from entering testing, I believe, because
 0.46 did compile on these architectures. (Correct me if I'm
 wrong about the criteria.)  0.46 used a different strategy -- it
 created DefaultHeaders.hs and other data files from templates
 before compiling, and didn't use template Haskell.
 
 My new plan is to wean pandoc off of template Haskell, which seems
 to be more trouble than it's worth.
 
 http://code.google.com/p/pandoc/issues/detail?id=186
 
 John
 
 I do not know these Haskell-specific details of coding style.  But
 if the new way is the proper way, then we do have the alternative
 of packaging only for those architectures supporting this better
 approach.

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?

 Do you perhaps have some references to discussions by others about
 template Haskell not working on some archs?  Perhaps the Debian
 Haskell team have discussed similar issues with other Haskell
 apps/libs?

In 7.9.2 of the following, it says you need a stage-2 compiler for
template Haskell:
http://www.haskell.org/ghc/docs/6.10-latest/html/users_guide/template-haskell.html

I'm not sure why several architectures only have a stage-1 GHC.
I'll ask around.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559978: FTBFS [hppa]: Template Haskell splice illegal in a stage-1 compiler

[John MacFarlane]

+++ dann frazier [Dec 07 09 19:37 ]:
 Package: pandoc
 Version: 1.2.1-1
 Severity: serious
 
 pandoc reliably fails to build on hppa:
   
 https://buildd.debian.org/build.php?pkg=pandocver=1.2.1-1arch=hppafile=log
 
 From the most recent build attempt:
 [...]
 Using pkg-config version 0.22 found on system at: /usr/bin/pkg-config
 Using ranlib found on system at: /usr/bin/ranlib
 Using strip found on system at: /usr/bin/strip
 Using tar found on system at: /bin/tar
 /usr/bin/gcc /tmp/23391.c -o /tmp/23391 -D__GLASGOW_HASKELL__=610 -I. 
 -D_HIGHLIGHTING -D_HIGHLIGHTING -I/usr/lib/ghc-6.10.4/process-1.0.1.1/include 
 -I/usr/lib/haskell-packages/ghc6/lib/network-2.2.1.4/ghc-6.10.4/include 
 -I/usr/lib/ghc-6.10.4/directory-1.0.0.3/include 
 -I/usr/lib/ghc-6.10.4/unix-2.3.2.0/include 
 -I/usr/lib/ghc-6.10.4/old-time-1.0.0.2/include 
 -I/usr/lib/ghc-6.10.4/bytestring-0.9.1.4/include 
 -I/usr/lib/ghc-6.10.4/base-4.1.0.0/include -I/usr/lib/ghc-6.10.4/include
 mv dist dist-ghc6
 mv dist-ghc6 dist
 debian/hlibrary.setup build
 Preprocessing library pandoc-1.2.1...
 Preprocessing executables for pandoc-1.2.1...
 Building pandoc-1.2.1...
 [ 1 of 29] Compiling Paths_pandoc ( dist/build/autogen/Paths_pandoc.hs, 
 dist/build/Paths_pandoc.o )
 [ 2 of 29] Compiling Text.Pandoc.XML  ( src/Text/Pandoc/XML.hs, 
 dist/build/Text/Pandoc/XML.o )
 [ 3 of 29] Compiling Text.Pandoc.CharacterReferences ( 
 src/Text/Pandoc/CharacterReferences.hs, 
 dist/build/Text/Pandoc/CharacterReferences.o )
 [ 4 of 29] Compiling Text.Pandoc.Definition ( src/Text/Pandoc/Definition.hs, 
 dist/build/Text/Pandoc/Definition.o )
 [ 5 of 29] Compiling Text.Pandoc.Shared ( src/Text/Pandoc/Shared.hs, 
 dist/build/Text/Pandoc/Shared.o )
 [ 6 of 29] Compiling Text.Pandoc.TH   ( src/Text/Pandoc/TH.hs, 
 dist/build/Text/Pandoc/TH.o )
 [ 7 of 29] Compiling Text.Pandoc.ODT  ( src/Text/Pandoc/ODT.hs, 
 dist/build/Text/Pandoc/ODT.o )
 
 src/Text/Pandoc/ODT.hs:49:24:
 Template Haskell splice illegal in a stage-1 compiler
   makeZip $ data / odt-styles
 make: *** [build-ghc6-stamp] Error 1

Pandoc, like many other Haskell programs, uses Template Haskell, which
requires a stage-2 compiler. I'm not sure why the ghc compiler on hppa
is only stage-1, but that would be the place to fix the problem.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500662: pandoc: reST comment blocks incorrectly interpreted

[John MacFarlane]

This problem has been fixed in the upstream source (pandoc-1.1).

+++ Ben Finney [Sep 30 08 18:29 ]:
 Package: pandoc
 Version: 0.46+2
 Severity: normal
 
 The reStructuredText specification allows for comment blocks of 
 arbitrary indented text 
 URL:http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#comments.
 
 The following session shows that pandoc is incorrectly interpreting 
 these comment elements as some other kind of element.
 
 =
 Script started on Tue 30 Sep 2008 18:03:08 EST
 
 $ infile=$(mktemp -t)
 $ cat  $infile
 Title of document
 =
 
 First paragraph
 
 ..
 Comment block, should not appear in output
 as defined by reStructuredText
 
 Another paragraph
 
 ..
 Another comment block.
 
 This one spans several
 text elements.
 
 It doesn't end until
 indentation is restored to the
 preceding level.
 
 A third paragraph
 
 $ pandoc --from rst --to markdown $infile
 # Title of document
 
 First paragraph
 
 ..
 :   Comment block, should not appear in output as defined by
 reStructuredText
 
 
 Another paragraph
 
 ..
  Another comment block.
  
  This one spans several text elements.
  
  It doesn't end until indentation is restored to the preceding
  level.
 
 A third paragraph
 
 $ rm $infile
 $ exit
 
 Script done on Tue 30 Sep 2008 18:07:49 EST
 =
 
 
 The above result is incorrect; instead the comment blocks in the input 
 should not be visible in the rendered form. For example, this would be 
 a correct rendering of the above example input:
 
 =
 # Title of document
 
 First paragraph
 
 Another paragraph
 
 A third paragraph
 
 =
 
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'stable'), (90, 'unstable')
 Architecture: powerpc (ppc64)
 
 Kernel: Linux 2.6.25-2-powerpc64 (SMP w/2 CPU cores)
 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_AU.UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages pandoc depends on:
 ii  libc6 2.7-13 GNU C Library: Shared libraries
 ii  libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
 
 pandoc recommends no packages.
 
 Versions of packages pandoc suggests:
 ii  tetex-extra2007.dfsg.1-3 TeX Live: teTeX transitional 
 packa
 ii  texlive-latex-recommended  2007.dfsg.1-3 TeX Live: LaTeX recommended 
 packag
 ii  tidy   20080116cvs-2 HTML syntax checker and 
 reformatte
 ii  wget   1.11.4-2  retrieves files from the web
 
 -- no debconf information
 
 -- 
  \“Politics is not the art of the possible. It consists in |
   `\   choosing between the disastrous and the unpalatable.” —John |
 _o__)Kenneth Galbraith, 1962-03-02 |
 Ben Finney [EMAIL PROTECTED]





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]