On Sun, Jul 05, 2020 at 05:58:57PM +0200, Adam Sjøgren wrote:
> I'm not sure where to start, or how I help most efficiently with getting
> pandoc updated, so xmonad can be.
>
> Maybe I should try to get rid of the dependency on Text.Pandoc in
> xmonad, it is only used to generate the man-page
Hello,
On Mon 13 Jul 2020 at 10:58PM +01, Barak A. Pearlmutter wrote:
> Sometimes I wonder if Debian needs some serious process analysis and
> restructuring. Should a new library version that happens to cross a major
> version boundary really good though the same extra vetting queue that a new
>
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 13 Jul 2020 22:19:13 +0200
Source: pandoc
Architecture: source
Version: 2.8.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Haskell Group
Changed-By: Jonas Smedegaard
Closes: 927689 959851 964822
pandoc_2.8.1-1_source.changes uploaded successfully to localhost
along with the files:
pandoc_2.8.1-1.dsc
pandoc_2.8.1.orig.tar.gz
pandoc_2.8.1-1.debian.tar.xz
pandoc_2.8.1-1_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Your message dated Mon, 13 Jul 2020 22:34:15 +
with message-id
and subject line Bug#964822: fixed in pandoc 2.8.1-1
has caused the Debian Bug report #964822,
regarding pandoc: BD-Uninstallable
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is
Your message dated Mon, 13 Jul 2020 22:34:15 +
with message-id
and subject line Bug#959851: fixed in pandoc 2.8.1-1
has caused the Debian Bug report #959851,
regarding pandoc: no warning fallback-parsing as markdown (expected fixed since
v2.8)
to be marked as done.
This means that you claim
Your message dated Mon, 13 Jul 2020 22:34:15 +
with message-id
and subject line Bug#927689: fixed in pandoc 2.8.1-1
has caused the Debian Bug report #927689,
regarding pandoc: Package version 2.7.2 or newer
to be marked as done.
This means that you claim that the problem has been dealt with.
Sometimes I wonder if Debian needs some serious process analysis and
restructuring. Should a new library version that happens to cross a major
version boundary really good though the same extra vetting queue that a new
browser goes through?
tldr: What have we wrought???
On Mon, Jul 13, 2020 at 09:05:28PM +0100, Barak A. Pearlmutter wrote:
> There's a new upstream version available, and I cannot update the
> github-backup package until libghc-github-dev (>= 0.23) is available.
> So I hope to see the new version packaged.
Someone would need to package
Quoting Clint Adams (2020-07-13 19:48:57)
> On Mon, Jul 13, 2020 at 12:21:22PM +0200, Jonas Smedegaard wrote:
> > I will only attempt patching _after_ haskell-doctemplates is installable
> > in unstable.
>
> It's now available on all release architectures but mipsel, mips64el,
> and s390x.
On Mon, Jul 13, 2020 at 12:21:22PM +0200, Jonas Smedegaard wrote:
> I will only attempt patching _after_ haskell-doctemplates is installable
> in unstable.
It's now available on all release architectures but mipsel, mips64el,
and s390x.
Quoting Jonas Smedegaard (2020-07-12 17:00:28)
> Quoting Jonas Smedegaard (2020-07-12 03:00:41)
> > Quoting Sean Whitton (2020-07-12 02:43:02)
> > > On Fri 12 Jun 2020 at 10:48PM +02, Jonas Smedegaard wrote:
> > > > Recent releases of Pandoc need these:
> > > >
> > > > * hslua-module-system >=
12 matches
Mail list logo
