Removing lua support would be most unfortunate! If you need help from upstream
in getting things to work, let me know.
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
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
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
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.
Note that highlighting-kate is deprecated and has been replaced
by the skylighting library, used in more recent versions of
pandoc.
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
>>
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...
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
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}
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
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
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
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 (
>
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
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
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:
-
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.
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
Upstream here: This should be very easy to fix.
The pandoc.1 man page is right in the tarball, in the man
directory.
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,
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
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
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
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
.
+++ 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
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
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)
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
+++ 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
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
+++ 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
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
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
+++ 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
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
+++ 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
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
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
+++ 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
+++ 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
+++ 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,
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
+++ 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
+++ 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.
+++ 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
+++ 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
+++ 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
+++ 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
+++ 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
+++ 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
+++ 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
+++ 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
+++ 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
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
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/)
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
+++ 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
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
59 matches
Mail list logo
