[maintainer update] pandoc 3.1.12.2

[Evan Silberman]

Bugfix release for pandoc, fixes a recent document-rendering regression
involving section numbering among other things.

Evan

---
commit 84a25862d3d3656f5f824cff7f643d8ced603747 (master)
from: Evan Silberman 
date: Fri Mar  1 23:52:37 2024 UTC
 
 Update pandoc to 3.1.12.2
 
diff 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4 
84a25862d3d3656f5f824cff7f643d8ced603747
commit - 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
commit + 84a25862d3d3656f5f824cff7f643d8ced603747
blob - e6b38f6738430522bca61316801e2bbf0a87210d
blob + 9439ecaf2361ad82514c0bca3a03063a442be1f5
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -1,7 +1,6 @@
-V =3.1.12.1
+V =3.1.12.2
 COMMENT =  convert between markup and document formats
 PKGNAME =  pandoc-${V}
-REVISION = 0
 
 CATEGORIES =   converters textproc
 
@@ -27,12 +26,6 @@ MODCABAL_STEM =  pandoc-cli
 MODCABAL_VERSION = ${V}
 MODCABAL_EXECUTABLES = pandoc
 
-post-install:
-   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc.1 
${PREFIX}/man/man1
-   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-lua.1 
${PREFIX}/man/man1
-   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-server.1 
${PREFIX}/man/man1
-
-
 MODCABAL_MANIFEST  = \
Glob0.10.2  3   \
HUnit   1.6.2.0 0   \
@@ -44,7 +37,7 @@ MODCABAL_MANIFEST = \
StateVar1.2.2   0   \
aeson   2.2.1.0 1   \
aeson-pretty0.8.10  0   \
-   alex3.5.0.0 0   \
+   alex3.5.1.0 0   \
ansi-terminal   1.1 0   \
ansi-terminal-types 1.1 0   \
appar   0.1.8   0   \
@@ -78,7 +71,7 @@ MODCABAL_MANIFEST = \
citeproc0.8.1   0   \
colour  2.3.6   0   \
commonmark  0.2.5.1 0   \
-   commonmark-extensions   0.2.5.2 0   \
+   commonmark-extensions   0.2.5.3 0   \
commonmark-pandoc   0.2.2.1 0   \
comonad 5.0.8   2   \
conduit 1.3.5   0   \
@@ -101,7 +94,7 @@ MODCABAL_MANIFEST= \
dec 0.0.5   2   \
digest  0.0.2.1 0   \
distributive0.6.2.1 1   \
-   djot0.1.0.0 0   \
+   djot0.1.1.0 0   \
dlist   1.0 1   \
doclayout   0.4.0.1 0   \
doctemplates0.110   \
@@ -157,7 +150,7 @@ MODCABAL_MANIFEST   = \
mime-types  0.1.2.0 0   \
mmorph  1.2.0   3   \
monad-control   1.0.3.1 0   \
-   mono-traversable1.0.15.30   \
+   mono-traversable1.0.17.00   \
network 3.1.4.0 1   \
network-byte-order  0.1.7   0   \
network-control 0.0.2   0   \
@@ -166,7 +159,7 @@ MODCABAL_MANIFEST   = \
old-time1.1.0.4 0   \
optparse-applicative0.18.1.00   \
ordered-containers  0.2.3   0   \
-   pandoc  3.1.12.10   \
+   pandoc  3.1.12.20   \
pandoc-lua-engine   0.2.1.3 0   \
pandoc-lua-marshal  0.2.4   0   \
pandoc-server   0.1.0.5 0   \
@@ -195,7 +188,7 @@ MODCABAL_MANIFEST   = \
skylighting 0.14.1  0   \
skylighting-core0.14.1  0   \
skylighting-format-ansi 0.1 0   \
-   skylighting-format-blaze-html   0.1.1.1 0   \
+   skylighting-format-blaze-html   0.1.1.2 0   \
skylighting-format-context  0.1.0.2 0   \
skylighting-format-latex0.1 0   \
socks   0.6.1   0   \
@@ -221,7 +214,7 @@ MODCABAL_MANIFEST   = \
these   1.2 1   \
time-compat 1.9.6.1 6   \
time-manager0.0.1   0   \
-   tls 2.0.0   0   \
+   tls 2.0.1   1   \
toml-parser 1.3.2.0 0   \
transformers-base   0.4.6   0   \
transformers-compat 0.7.2   0   \
@@ -259,4 +252,10 @@ MODCABAL_MANIFEST  = \
zip-archive 0.4.3   0   \
zlib0.6.3.0 4   \
 
+post-install:
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc.1 
${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-lua.1 
${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-server.1 
${PREFIX}/man/man1
+
+
 .include 
blob - b68e138d2bc28e0f328e26dde5d9c0ac009af898
blob + f84c29b79ca09f5c9bdedd3cb954153379c51b32
--- textproc/pandoc/distinfo
+++ textproc/pandoc/distinfo
@@ -13,7 +13,7 @@ SHA256 (hackage/StateVar-1.2.2.tar.gz) = Xks52jlWVqWYJ
 SHA256 (hackage/aeson-2.2.1.0.tar.gz) = 
kU7v0OgNEttcch2qLLq0J6zuOXlfElxUYMH+SM+aXX8=
 SHA256 (hackage/aeson-2.2.1.0_1.cabal) = 
ojphqtqCM+EFc+FhLAsu/loaug1ZsF2+L2MwGCLxNss=
 SHA256 (hackage/aeson-pretty-0.8.10.tar.gz

Re: pandoc: pkg-readme concerning PDF output

[Dima Pasechnik]

On Sun, Feb 25, 2024 at 11:50:28AM -0800, Evan Silberman wrote:
> job@ emailed me asking why PDF output for pandoc via LaTeX was failing.
> Here's a pkg-readme about that.
> 
> ---
> commit 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4 (master)
> from: Evan Silberman 
> date: Sun Feb 25 19:48:17 2024 UTC
>  
>  Add a pkg-readme concerning PDF output
>  
> diff a18126b97cb145ff893d6fd7356f0af4cfb07383 
> 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
> commit - a18126b97cb145ff893d6fd7356f0af4cfb07383
> commit + 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
> blob - ab326cff68ef82345156ce5a9c598d7d043b8c5d
> blob + e6b38f6738430522bca61316801e2bbf0a87210d
> --- textproc/pandoc/Makefile
> +++ textproc/pandoc/Makefile
> @@ -1,6 +1,7 @@
>  V =  3.1.12.1
>  COMMENT =    convert between markup and document formats
>  PKGNAME =pandoc-${V}
> +REVISION =   0
>  
>  CATEGORIES = converters textproc
>  
> blob - 4ebc16ad3a98cae122f25b75c1dba37c3106c7a7
> blob + 8cc3b2217127fa785a3dd84d6c11967a320e3bce
> --- textproc/pandoc/pkg/PLIST
> +++ textproc/pandoc/pkg/PLIST
> @@ -2,3 +2,4 @@
>  @man man/man1/pandoc-lua.1
>  @man man/man1/pandoc-server.1
>  @man man/man1/pandoc.1
> +share/doc/pkg-readmes/${PKGSTEM}
> blob - /dev/null
> blob + c959cfa7bfa1231cec8ddb7ed88f2be5e86a5083 (mode 644)
> --- /dev/null
> +++ textproc/pandoc/pkg/README
> @@ -0,0 +1,27 @@
> +PDF output for pandoc on OpenBSD
> +
> +
> +Pandoc's PDF output mode relies on external programs to render a PDF from a
> +markup format. By default, PDF output uses LaTeX and pandoc's default LaTeX
> +template requires a number of common packages. On OpenBSD, installing
> +texlive_texmf-minimal is sufficient for pandoc to generate PDFs via LaTeX.
> +
> +The table below lists the PDF engines directly supported by pandoc for each
> +output format and, when available, the OpenBSD package providing the required
> +executable. For complete details on the --pdf-engine option see the pandoc
> +manual.
> +
> +Output format PDF Engine  OpenBSD package
> +----- 
> +latex latexmk latexmk

I won't call latexmk "PDF Engine". Latexmk is an engine-agnostic
stript to run pdf/lua/xe/latex sufficiently many times (perhaps 
adding a call to biber or bibtex) to produce the final result.
It won't work without the appropriate engine installed.

> +latex lualatextexlive_base
> +latex pdflatextexlive_base
> +latex tectonicn/a (not in ports)
> +latex xelatex texlive_texmf-minimal
> +context   context texlive_texmf-context (broken on OpenBSD)
> +html  pagedjs-cli n/a (NPM package)
> +html  prince  n/a (commercial/proprietary)
> +html  weasyprint  weasyprint
> +html  wkhtmltopdf wkhtmltopdf
> +mspdfroff groff
> +typst typst   n/a (not in ports)
> 

I'd also say that a popular pandoc LaTeX output format is beamer (beamer is a
LaTeX package to create presentations), which, I
think, is in full texlive, not minimal, on OpenBSD. And beamer output
format can also be used to output pdfs. So it seems it's missing in the
table, and it also contracdicts the claim above that 
texlive_texmf-minimal is always sufficient.

Best,
Dima

Re: pandoc: pkg-readme concerning PDF output

[Evan Silberman]

Dima Pasechnik  wrote:
> On Sun, Feb 25, 2024 at 11:50:28AM -0800, Evan Silberman wrote:
> > job@ emailed me asking why PDF output for pandoc via LaTeX was failing.
> > Here's a pkg-readme about that.
> > 
> > ---
> > commit 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4 (master)
> > from: Evan Silberman 
> > date: Sun Feb 25 19:48:17 2024 UTC
> >  
> >  Add a pkg-readme concerning PDF output
> >  
> > diff a18126b97cb145ff893d6fd7356f0af4cfb07383 
> > 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
> > commit - a18126b97cb145ff893d6fd7356f0af4cfb07383
> > commit + 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
> > blob - ab326cff68ef82345156ce5a9c598d7d043b8c5d
> > blob + e6b38f6738430522bca61316801e2bbf0a87210d
> > --- textproc/pandoc/Makefile
> > +++ textproc/pandoc/Makefile
> > @@ -1,6 +1,7 @@
> >  V =3.1.12.1
> >  COMMENT =  convert between markup and document formats
> >  PKGNAME =  pandoc-${V}
> > +REVISION = 0
> >  
> >  CATEGORIES =   converters textproc
> >  
> > blob - 4ebc16ad3a98cae122f25b75c1dba37c3106c7a7
> > blob + 8cc3b2217127fa785a3dd84d6c11967a320e3bce
> > --- textproc/pandoc/pkg/PLIST
> > +++ textproc/pandoc/pkg/PLIST
> > @@ -2,3 +2,4 @@
> >  @man man/man1/pandoc-lua.1
> >  @man man/man1/pandoc-server.1
> >  @man man/man1/pandoc.1
> > +share/doc/pkg-readmes/${PKGSTEM}
> > blob - /dev/null
> > blob + c959cfa7bfa1231cec8ddb7ed88f2be5e86a5083 (mode 644)
> > --- /dev/null
> > +++ textproc/pandoc/pkg/README
> > @@ -0,0 +1,27 @@
> > +PDF output for pandoc on OpenBSD
> > +
> > +
> > +Pandoc's PDF output mode relies on external programs to render a PDF from a
> > +markup format. By default, PDF output uses LaTeX and pandoc's default LaTeX
> > +template requires a number of common packages. On OpenBSD, installing
> > +texlive_texmf-minimal is sufficient for pandoc to generate PDFs via LaTeX.
> > +
> > +The table below lists the PDF engines directly supported by pandoc for each
> > +output format and, when available, the OpenBSD package providing the 
> > required
> > +executable. For complete details on the --pdf-engine option see the pandoc
> > +manual.
> > +
> > +Output format PDF Engine  OpenBSD package
> > +----- ----
> > +latex latexmk latexmk
> 
> I won't call latexmk "PDF Engine". Latexmk is an engine-agnostic
> stript to run pdf/lua/xe/latex sufficiently many times (perhaps 
> adding a call to biber or bibtex) to produce the final result.
> It won't work without the appropriate engine installed.

"PDF engine" is the term pandoc uses, 'latexmk' is a valid argument
to pandoc's --pdf-engine option, and there's an OpenBSD package that
provides the required command. That's all I'm trying to document.

> 
> > +latex lualatextexlive_base
> > +latex pdflatextexlive_base
> > +latex tectonicn/a (not in ports)
> > +latex xelatex texlive_texmf-minimal
> > +context   context texlive_texmf-context (broken on OpenBSD)
> > +html  pagedjs-cli n/a (NPM package)
> > +html  prince  n/a (commercial/proprietary)
> > +html  weasyprint  weasyprint
> > +html  wkhtmltopdf wkhtmltopdf
> > +mspdfroff groff
> > +typst typst   n/a (not in ports)
> > 
> 
> I'd also say that a popular pandoc LaTeX output format is beamer (beamer is a
> LaTeX package to create presentations), which, I
> think, is in full texlive, not minimal, on OpenBSD. And beamer output
> format can also be used to output pdfs. So it seems it's missing in the
> table, and it also contracdicts the claim above that 
> texlive_texmf-minimal is always sufficient.

beamer is in texlive_texmf-minimal. Beamer also isn't listed separately
in pandoc's documentation of PDF engines supported by output formats. I
could add a note about beamer here but I don't think anyone would be
lost or confused without it.

Evan

pandoc: pkg-readme concerning PDF output

[Evan Silberman]

job@ emailed me asking why PDF output for pandoc via LaTeX was failing.
Here's a pkg-readme about that.

---
commit 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4 (master)
from: Evan Silberman 
date: Sun Feb 25 19:48:17 2024 UTC
 
 Add a pkg-readme concerning PDF output
 
diff a18126b97cb145ff893d6fd7356f0af4cfb07383 
86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
commit - a18126b97cb145ff893d6fd7356f0af4cfb07383
commit + 86a9ed9487281ed9cebbbcfda4d3989dc603a1c4
blob - ab326cff68ef82345156ce5a9c598d7d043b8c5d
blob + e6b38f6738430522bca61316801e2bbf0a87210d
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -1,6 +1,7 @@
 V =3.1.12.1
 COMMENT =  convert between markup and document formats
 PKGNAME =  pandoc-${V}
+REVISION = 0
 
 CATEGORIES =   converters textproc
 
blob - 4ebc16ad3a98cae122f25b75c1dba37c3106c7a7
blob + 8cc3b2217127fa785a3dd84d6c11967a320e3bce
--- textproc/pandoc/pkg/PLIST
+++ textproc/pandoc/pkg/PLIST
@@ -2,3 +2,4 @@
 @man man/man1/pandoc-lua.1
 @man man/man1/pandoc-server.1
 @man man/man1/pandoc.1
+share/doc/pkg-readmes/${PKGSTEM}
blob - /dev/null
blob + c959cfa7bfa1231cec8ddb7ed88f2be5e86a5083 (mode 644)
--- /dev/null
+++ textproc/pandoc/pkg/README
@@ -0,0 +1,27 @@
+PDF output for pandoc on OpenBSD
+
+
+Pandoc's PDF output mode relies on external programs to render a PDF from a
+markup format. By default, PDF output uses LaTeX and pandoc's default LaTeX
+template requires a number of common packages. On OpenBSD, installing
+texlive_texmf-minimal is sufficient for pandoc to generate PDFs via LaTeX.
+
+The table below lists the PDF engines directly supported by pandoc for each
+output format and, when available, the OpenBSD package providing the required
+executable. For complete details on the --pdf-engine option see the pandoc
+manual.
+
+Output format PDF Engine  OpenBSD package
+----- 
+latex latexmk latexmk
+latex lualatextexlive_base
+latex pdflatextexlive_base
+latex tectonicn/a (not in ports)
+latex xelatex texlive_texmf-minimal
+context   context texlive_texmf-context (broken on OpenBSD)
+html  pagedjs-cli n/a (NPM package)
+html  prince  n/a (commercial/proprietary)
+html  weasyprint  weasyprint
+html  wkhtmltopdf wkhtmltopdf
+mspdfroff groff
+typst typst   n/a (not in ports)

Re: [maintainer update] pandoc 3.1.12.1

[Greg Steuck]

Evan Silberman  writes:
> Fairly straightforward now that I can build working Haskell programs on
> here again. The version of the pandoc-cli package is now 1:1 with the
> pandoc version so packaging is a bit easier. The manuals for the
> pandoc-server and pandoc-lua modes are also packaged now.

Thanks for the update, works for me too.

Thanks
Greg

[maintainer update] pandoc 3.1.12.1

[Evan Silberman]

Hi Greg + ports,

Fairly straightforward now that I can build working Haskell programs on
here again. The version of the pandoc-cli package is now 1:1 with the
pandoc version so packaging is a bit easier. The manuals for the
pandoc-server and pandoc-lua modes are also packaged now.

Thanks,
Evan


---
commit a18126b97cb145ff893d6fd7356f0af4cfb07383 (master)
from: Evan Silberman 
date: Sat Feb 24 05:45:40 2024 UTC
 
 Update to pandoc 3.1.12.1
 
diff 3099dc2614141a5fae4eb3a053c9cf54597a0aa9 
a18126b97cb145ff893d6fd7356f0af4cfb07383
commit - 3099dc2614141a5fae4eb3a053c9cf54597a0aa9
commit + a18126b97cb145ff893d6fd7356f0af4cfb07383
blob - 81605f64782f583f6ec33174c85a1ad7e322b0bd
blob + ab326cff68ef82345156ce5a9c598d7d043b8c5d
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -1,4 +1,4 @@
-V =3.1.8
+V =3.1.12.1
 COMMENT =  convert between markup and document formats
 PKGNAME =  pandoc-${V}
 
@@ -23,230 +23,232 @@ NO_TEST = Yes
 MODULES =  devel/cabal
 MODCABAL_FLAGS =   embed_data_files
 MODCABAL_STEM =pandoc-cli
-MODCABAL_VERSION = 0.1.1.1
+MODCABAL_VERSION = ${V}
 MODCABAL_EXECUTABLES = pandoc
 
 post-install:
-   ${INSTALL_MAN} ${WRKDIR}/${PKGNAME}/man/pandoc.1 ${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc.1 
${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-lua.1 
${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${MODCABAL_STEM}-${V}/man/pandoc-server.1 
${PREFIX}/man/man1
 
 
 MODCABAL_MANIFEST  = \
Glob0.10.2  3   \
HUnit   1.6.2.0 0   \
-   JuicyPixels 3.3.8   0   \
-   OneTuple0.4.1.1 0   \
+   JuicyPixels 3.3.8   1   \
+   OneTuple0.4.1.1 1   \
Only0.1 2   \
QuickCheck  2.14.3  0   \
SHA 1.6.4.4 0   \
StateVar1.2.2   0   \
-   aeson   2.1.2.1 3   \
+   aeson   2.2.1.0 1   \
aeson-pretty0.8.10  0   \
-   alex3.4.0.0 0   \
-   ansi-terminal   1.0 0   \
-   ansi-terminal-types 0.11.5  1   \
+   alex3.5.0.0 0   \
+   ansi-terminal   1.1 0   \
+   ansi-terminal-types 1.1 0   \
appar   0.1.8   0   \
asn1-encoding   0.9.6   2   \
asn1-parse  0.9.5   0   \
asn1-types  0.3.4   0   \
-   assoc   1.1 0   \
-   async   2.2.4   3   \
-   attoparsec  0.14.4  4   \
+   assoc   1.1 1   \
+   async   2.2.5   0   \
+   attoparsec  0.14.4  5   \
auto-update 0.1.6   0   \
-   base-compat 0.13.0  0   \
-   base-compat-batteries   0.13.0  0   \
-   base-orphans0.9.0   0   \
+   base-compat 0.13.1  0   \
+   base-orphans0.9.1   0   \
base-unicode-symbols0.2.4.2 0   \
-   base16-bytestring   1.0.2.0 0   \
-   base64  0.4.2.4 3   \
+   base16-bytestring   1.0.2.0 1   \
base64-bytestring   1.2.1.0 1   \
basement0.0.16  0   \
-   bifunctors  5.6.1   1   \
+   bifunctors  5.6.1   2   \
bitvec  1.1.5.0 0   \
blaze-builder   0.4.2.3 0   \
blaze-html  0.9.1.2 4   \
-   blaze-markup0.8.3.0 0   \
-   boring  0.2.1   0   \
-   bsb-http-chunked0.0.0.4 3   \
+   blaze-markup0.8.3.0 1   \
+   boring  0.2.1   1   \
+   bsb-http-chunked0.0.0.4 4   \
byteorder   1.0.4   0   \
cabal-doctest   1.0.9   3   \
call-stack  0.4.0   0   \
case-insensitive1.2.1.0 0   \
-   cassava 0.5.3.0 4   \
+   cassava 0.5.3.0 5   \
+   cborg   0.2.10.00   \
cereal  0.5.8.3 0   \
citeproc0.8.1   0   \
colour  2.3.6   0   \
-   commonmark  0.2.3   0   \
-   commonmark-extensions   0.2.3.6 0   \
-   commonmark-pandoc   0.2.1.3 0   \
-   comonad 5.0.8   1   \
+   commonmark  0.2.5.1 0   \
+   commonmark-extensions   0.2.5.2 0   \
+   commonmark-pandoc   0.2.2.1 0   \
+   comonad 5.0.8   2   \
conduit 1.3.5   0   \
conduit-extra   1.3.6   0   \
-   constraints 0.13.4  1   \
+   constraints 0.140   \
contravariant   1.5.5   0   \
cookie  0.4.6   0   \
-   crypton 0.330   \
-   crypton-connection  0.3.1   0   \
+   crypton 0.340   \
+   crypton-connection  0.3.2   0   \
crypton-x5091.7.6   1   \
crypton-x509-store  1.6.9   0

Re: Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)

[Marc Espie]

Fight or flight.

There is a point where you still need to enforce some basic semantics
and refuse files that don't conform.

I would question leading white space in .pc files even though pkgconf
would be happy with them.

Re: Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)

[Theo Buehler]

On Sat, Oct 07, 2023 at 07:27:51PM +0200, Theo Buehler wrote:
> On Sat, Oct 07, 2023 at 10:04:35AM -0700, Greg Steuck wrote:
> > Theo Buehler  writes:
> > 
> > >> Alright. I've added that and will let you know if it happens again.
> > >
> > > This gives slightly more info. No change in the rest of the log except
> > > time stamps.
> > 
> > I'm pretty sure this is both new and actionable:
> > 
> > > Running: /usr/bin/pkg-config --version
> > > Running: /usr/bin/pkg-config --variable pc_path pkg-config
> > > Running: /usr/bin/pkg-config --version
> > > Running: /usr/bin/pkg-config --list-all
> > > Failed to query pkg-config, Cabal will continue without solving for 
> > > pkg-config
> > > constraints: dieVerbatim: user error (CallStack (from HasCallStack):
> > > withMetadata, called at src/Distribution/Simple/Utils.hs:368:14 in
> > > Cabal-3.10.1.0-KNis1qL4Wul5JivvGU00XF:Distribution.Simple.Utils
> > > Error: cabal: '/usr/bin/pkg-config' exited with an error:
> > > Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
> > 
> > I don't normally have /usr/local/lib/pkgconfig/dcmtk.pc, installing
> > graphics/dcmtk allows me to reproduce the bug. In particular, something
> > is fishy about this file or pkg-config:
> 
> The file has a single space leading whitespace. pkgconf can deal with
> it, base pkg-config can't.

Apparently other pkgconf implementations also have issues. Upstream
removed the offending whitespace.

https://github.com/DCMTK/dcmtk/pull/82

Re: Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)

[Theo Buehler]

On Sat, Oct 07, 2023 at 10:04:35AM -0700, Greg Steuck wrote:
> Theo Buehler  writes:
> 
> >> Alright. I've added that and will let you know if it happens again.
> >
> > This gives slightly more info. No change in the rest of the log except
> > time stamps.
> 
> I'm pretty sure this is both new and actionable:
> 
> > Running: /usr/bin/pkg-config --version
> > Running: /usr/bin/pkg-config --variable pc_path pkg-config
> > Running: /usr/bin/pkg-config --version
> > Running: /usr/bin/pkg-config --list-all
> > Failed to query pkg-config, Cabal will continue without solving for 
> > pkg-config
> > constraints: dieVerbatim: user error (CallStack (from HasCallStack):
> > withMetadata, called at src/Distribution/Simple/Utils.hs:368:14 in
> > Cabal-3.10.1.0-KNis1qL4Wul5JivvGU00XF:Distribution.Simple.Utils
> > Error: cabal: '/usr/bin/pkg-config' exited with an error:
> > Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
> 
> I don't normally have /usr/local/lib/pkgconfig/dcmtk.pc, installing
> graphics/dcmtk allows me to reproduce the bug. In particular, something
> is fishy about this file or pkg-config:

The file has a single space leading whitespace. pkgconf can deal with
it, base pkg-config can't.

> 
> % /usr/bin/pkg-config --list-all > /dev/null
> Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
> % echo $?
> 1
> % pkg-config --exists dcmtk
> % echo $?
> 1
> % ls -l /usr/local/lib/pkgconfig/dcmtk.pc
> -rw-r--r--  1 root  bin  666 Oct  5 04:36 /usr/local/lib/pkgconfig/dcmtk.pc
> 
> Thanks
> Greg

Re: Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)

[Peter Hessler]

On 2023 Oct 07 (Sat) at 10:04:35 -0700 (-0700), Greg Steuck wrote:
:Theo Buehler  writes:
:
:>> Alright. I've added that and will let you know if it happens again.
:>
:> This gives slightly more info. No change in the rest of the log except
:> time stamps.
:
:I'm pretty sure this is both new and actionable:
:
:> Running: /usr/bin/pkg-config --version
:> Running: /usr/bin/pkg-config --variable pc_path pkg-config
:> Running: /usr/bin/pkg-config --version
:> Running: /usr/bin/pkg-config --list-all
:> Failed to query pkg-config, Cabal will continue without solving for 
pkg-config
:> constraints: dieVerbatim: user error (CallStack (from HasCallStack):
:> withMetadata, called at src/Distribution/Simple/Utils.hs:368:14 in
:> Cabal-3.10.1.0-KNis1qL4Wul5JivvGU00XF:Distribution.Simple.Utils
:> Error: cabal: '/usr/bin/pkg-config' exited with an error:
:> Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
:
:I don't normally have /usr/local/lib/pkgconfig/dcmtk.pc, installing
:graphics/dcmtk allows me to reproduce the bug. In particular, something
:is fishy about this file or pkg-config:
:
:% /usr/bin/pkg-config --list-all > /dev/null
:Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
:% echo $?
:1
:% pkg-config --exists dcmtk
:% echo $?
:1
:% ls -l /usr/local/lib/pkgconfig/dcmtk.pc
:-rw-r--r--  1 root  bin  666 Oct  5 04:36 /usr/local/lib/pkgconfig/dcmtk.pc
:
:Thanks
:Greg
:

I can reproduce it here as well.  It seems every line is prefixed with a
single space (e.g. ' Name: DCMTK'), which causes the problem.  If I
manually remove the leading space, then dcmtk.pc seems to be alright.


-- 
Boston, n.:
Ludwig van Beethoven being jeered by 50,000 sports fans for
finishing second in the Irish jig competition.

Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)

[Greg Steuck]

Theo Buehler  writes:

>> Alright. I've added that and will let you know if it happens again.
>
> This gives slightly more info. No change in the rest of the log except
> time stamps.

I'm pretty sure this is both new and actionable:

> Running: /usr/bin/pkg-config --version
> Running: /usr/bin/pkg-config --variable pc_path pkg-config
> Running: /usr/bin/pkg-config --version
> Running: /usr/bin/pkg-config --list-all
> Failed to query pkg-config, Cabal will continue without solving for pkg-config
> constraints: dieVerbatim: user error (CallStack (from HasCallStack):
> withMetadata, called at src/Distribution/Simple/Utils.hs:368:14 in
> Cabal-3.10.1.0-KNis1qL4Wul5JivvGU00XF:Distribution.Simple.Utils
> Error: cabal: '/usr/bin/pkg-config' exited with an error:
> Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc

I don't normally have /usr/local/lib/pkgconfig/dcmtk.pc, installing
graphics/dcmtk allows me to reproduce the bug. In particular, something
is fishy about this file or pkg-config:

% /usr/bin/pkg-config --list-all > /dev/null
Problem reading file /usr/local/lib/pkgconfig/dcmtk.pc
% echo $?
1
% pkg-config --exists dcmtk
% echo $?
1
% ls -l /usr/local/lib/pkgconfig/dcmtk.pc
-rw-r--r--  1 root  bin  666 Oct  5 04:36 /usr/local/lib/pkgconfig/dcmtk.pc

Thanks
Greg

Re: [maintainer update] pandoc 3.1.8

[Theo Buehler]

On Fri, Oct 06, 2023 at 07:05:45PM +0200, Theo Buehler wrote:
> On Fri, Oct 06, 2023 at 10:02:35AM -0700, Greg Steuck wrote:
> > Theo Buehler  writes:
> > 
> > > On Fri, Oct 06, 2023 at 08:38:12AM -0700, Evan Silberman wrote:
> > >> Evan Silberman  wrote:
> > >> > Can't tell you why this cropped up for you and not me and Greg but 
> > >> > would
> > >> > you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your 
> > >> > build?
> > >> 
> > >> Sorry, should probably be MODCABAL_BUILD_ARGS='-c "digest -pkg-config"'.
> > >
> > > I can... It is my first bulk build where this fails. It built in my last
> > > few bulks. So most likely some dependency is assumed to be present which
> > > isn't necessarily there during a bulk.
> > 
> > Naturally I can't reproduce this in isolation. If get into a state where
> > you can reproduce this without dpb, maybe getting more diagnostics with
> > MODCABAL_BUILD_ARGS='-v' will help us figure out what goes sideways.
> 
> Alright. I've added that and will let you know if it happens again.

This gives slightly more info. No change in the rest of the log except
time stamps.

===>  Building for pandoc-3.1.8
Project settings changed, reconfiguring...
creating /tmp/pobj/pandoc-3.1.8/pandoc-cli-0.1.1.1/dist-newstyle
creating /tmp/pobj/pandoc-3.1.8/pandoc-cli-0.1.1.1/dist-newstyle/cache
The package description file /tmp/pobj/pandoc-3.1.8/appar-0.1.8/appar.cabal
has warnings: /tmp/pobj/pandoc-3.1.8/appar-0.1.8/appar.cabal:20:37: version
operators used. To use version operators the package needs to specify at least
'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/asn1-parse-0.9.5/asn1-parse.cabal has warnings:
/tmp/pobj/pandoc-3.1.8/asn1-parse-0.9.5/asn1-parse.cabal:17:34: version
operators used. To use version operators the package needs to specify at least
'cabal-version: >= 1.8'.
/tmp/pobj/pandoc-3.1.8/asn1-parse-0.9.5/asn1-parse.cabal:19:42: version
operators used. To use version operators the package needs to specify at least
'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/asn1-types-0.3.4/asn1-types.cabal has warnings:
/tmp/pobj/pandoc-3.1.8/asn1-types-0.3.4/asn1-types.cabal:17:34: version
operators used. To use version operators the package needs to specify at least
'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/base-unicode-symbols-0.2.4.2/base-unicode-symbols.cabal
has warnings:
/tmp/pobj/pandoc-3.1.8/base-unicode-symbols-0.2.4.2/base-unicode-symbols.cabal:59:40:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
/tmp/pobj/pandoc-3.1.8/base-unicode-symbols-0.2.4.2/base-unicode-symbols.cabal:56:40:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
/tmp/pobj/pandoc-3.1.8/base-unicode-symbols-0.2.4.2/base-unicode-symbols.cabal:52:34:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/data-default-0.7.1.1/data-default.cabal has warnings:
/tmp/pobj/pandoc-3.1.8/data-default-0.7.1.1/data-default.cabal:17:33: version
operators used. To use version operators the package needs to specify at least
'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/data-default-class-0.1.2.0/data-default-class.cabal has
warnings:
/tmp/pobj/pandoc-3.1.8/data-default-class-0.1.2.0/data-default-class.cabal:17:33:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/data-default-instances-containers-0.0.1/data-default-instances-containers.cabal
has warnings:
/tmp/pobj/pandoc-3.1.8/data-default-instances-containers-0.0.1/data-default-instances-containers.cabal:17:33:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/data-default-instances-dlist-0.0.1/data-default-instances-dlist.cabal
has warnings:
/tmp/pobj/pandoc-3.1.8/data-default-instances-dlist-0.0.1/data-default-instances-dlist.cabal:17:33:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
The package description file
/tmp/pobj/pandoc-3.1.8/data-default-instances-old-locale-0.0.1/data-default-instances-old-locale.cabal
has warnings:
/tmp/pobj/pandoc-3.1.8/data-default-instances-old-locale-0.0.1/data-default-instances-old-locale.cabal:17:33:
version operators used. To use version operators the package needs to specify
at least 'cabal-version: >= 1.8'.
The package description file /

Re: [maintainer update] pandoc 3.1.8

[Theo Buehler]

On Fri, Oct 06, 2023 at 10:02:35AM -0700, Greg Steuck wrote:
> Theo Buehler  writes:
> 
> > On Fri, Oct 06, 2023 at 08:38:12AM -0700, Evan Silberman wrote:
> >> Evan Silberman  wrote:
> >> > Can't tell you why this cropped up for you and not me and Greg but would
> >> > you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?
> >> 
> >> Sorry, should probably be MODCABAL_BUILD_ARGS='-c "digest -pkg-config"'.
> >
> > I can... It is my first bulk build where this fails. It built in my last
> > few bulks. So most likely some dependency is assumed to be present which
> > isn't necessarily there during a bulk.
> 
> Naturally I can't reproduce this in isolation. If get into a state where
> you can reproduce this without dpb, maybe getting more diagnostics with
> MODCABAL_BUILD_ARGS='-v' will help us figure out what goes sideways.

Alright. I've added that and will let you know if it happens again.

> 
> Thanks
> Greg

Re: [maintainer update] pandoc 3.1.8

[Greg Steuck]

Theo Buehler  writes:

> On Fri, Oct 06, 2023 at 08:38:12AM -0700, Evan Silberman wrote:
>> Evan Silberman  wrote:
>> > Can't tell you why this cropped up for you and not me and Greg but would
>> > you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?
>> 
>> Sorry, should probably be MODCABAL_BUILD_ARGS='-c "digest -pkg-config"'.
>
> I can... It is my first bulk build where this fails. It built in my last
> few bulks. So most likely some dependency is assumed to be present which
> isn't necessarily there during a bulk.

Naturally I can't reproduce this in isolation. If get into a state where
you can reproduce this without dpb, maybe getting more diagnostics with
MODCABAL_BUILD_ARGS='-v' will help us figure out what goes sideways.

Thanks
Greg

Re: [maintainer update] pandoc 3.1.8

[Theo Buehler]

On Fri, Oct 06, 2023 at 08:38:12AM -0700, Evan Silberman wrote:
> Evan Silberman  wrote:
> > Can't tell you why this cropped up for you and not me and Greg but would
> > you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?
> 
> Sorry, should probably be MODCABAL_BUILD_ARGS='-c "digest -pkg-config"'.

I can... It is my first bulk build where this fails. It built in my last
few bulks. So most likely some dependency is assumed to be present which
isn't necessarily there during a bulk.

Re: [maintainer update] pandoc 3.1.8

[Evan Silberman]

Evan Silberman  wrote:
> Can't tell you why this cropped up for you and not me and Greg but would
> you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?

Sorry, should probably be MODCABAL_BUILD_ARGS='-c "digest -pkg-config"'.

E

Re: [maintainer update] pandoc 3.1.8

[Evan Silberman]

Theo Buehler  wrote:
> On Tue, Sep 26, 2023 at 09:16:44AM -0700, Greg Steuck wrote:
> > Hi Evan,
> > 
> > Evan Silberman  writes:
> > 
> > > Hi Greg, ports,
> > >
> > > Straightforward upgrade of Pandoc to 3.1.8 from a couple weeks ago,
> > > hoping to go in before ports freeze. (I only sit down to do this every
> > > so often so I was sort of playing chicken with the release cycle in case
> > > there was a bugfix release shortly after 3.1.8 here)
> > 
> > Thank you, I minimally tested the package and committed it.
> 
> Ran into a build failure with this, full log below:
> 
> ===>  Building for pandoc-3.1.8
> Warning: No remote package servers have been specified. Usually you would have
> one specified in the config file.
> Resolving dependencies...
> Error: cabal: Could not resolve dependencies:
> [__0] trying: digest-0.0.1.7 (user goal)
> [__1] rejecting: digest:+pkg-config (conflict: pkg-config package zlib-any,
> not found in the pkg-config database)
> [__1] rejecting: digest:-pkg-config (manual flag can only be changed
> explicitly)
> [__1] fail (backjumping, conflict set: digest, digest:pkg-config)
> After searching the rest of the dependency tree exhaustively, these were the
> goals I've had most trouble fulfilling: digest, digest:pkg-config

Hi Theo,

Can't tell you why this cropped up for you and not me and Greg but would
you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?
This should force the solver to build digest without using pkg-config,
which should be fine on OpenBSD because base zlib will be picked up.

Heading out of town in a few hours, hope this unsticks.

Evan

Re: [maintainer update] pandoc 3.1.8

[Theo Buehler]

On Tue, Sep 26, 2023 at 09:16:44AM -0700, Greg Steuck wrote:
> Hi Evan,
> 
> Evan Silberman  writes:
> 
> > Hi Greg, ports,
> >
> > Straightforward upgrade of Pandoc to 3.1.8 from a couple weeks ago,
> > hoping to go in before ports freeze. (I only sit down to do this every
> > so often so I was sort of playing chicken with the release cycle in case
> > there was a bugfix release shortly after 3.1.8 here)
> 
> Thank you, I minimally tested the package and committed it.

Ran into a build failure with this, full log below:

===>  Building for pandoc-3.1.8
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: digest-0.0.1.7 (user goal)
[__1] rejecting: digest:+pkg-config (conflict: pkg-config package zlib-any,
not found in the pkg-config database)
[__1] rejecting: digest:-pkg-config (manual flag can only be changed
explicitly)
[__1] fail (backjumping, conflict set: digest, digest:pkg-config)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: digest, digest:pkg-config

>>> Building on localhost under textproc/pandoc
BDEPENDS = 
[devel/libffi;devel/cabal-install;devel/gmp;converters/libiconv;lang/ghc]
DIST = 
[textproc/pandoc:hackage/hslua-classes-2.3.0.tar.gz;productivity/hledger:hackage/generically-0.1.1_1.cabal;devel/cabal-bundler:hackage/attoparsec-0.14.4.tar.gz;devel/darcs:hackage/asn1-encoding-0.9.6.tar.gz;textproc/pandoc:hackage/hslua-aeson-2.3.0.1.tar.gz;textproc/pandoc:hackage/http-api-data-0.6.tar.gz;devel/cabal-bundler:hackage/time-compat-1.9.6.1.tar.gz;productivity/hledger:hackage/base-compat-0.13.0.tar.gz;devel/git-annex:hackage/bsb-http-chunked-0.0.0.4.tar.gz;textproc/pandoc:hackage/haddock-library-1.11.0_2.cabal;textproc/pandoc:hackage/unicode-transforms-0.4.0.1.tar.gz;textproc/pandoc:hackage/digest-0.0.1.7_1.cabal;devel/darcs:hackage/asn1-parse-0.9.5.tar.gz;textproc/pandoc:hackage/base-compat-batteries-0.13.0.tar.gz;devel/git-annex:hackage/cabal-doctest-1.0.9.tar.gz;textproc/pandoc:hackage/singleton-bool-0.1.7.tar.gz;devel/cabal-bundler:hackage/Glob-0.10.2_3.cabal;textproc/pandoc:hackage/skylighting-0.14.tar.gz;textproc/pandoc:hackage/yaml-0.11.11.2.tar.gz;productivity/hledger:hackage/assoc-1.1.tar.gz;devel/cabal-install:hackage/regex-base-0.94.0.2.tar.gz;productivity/hledger:hackage/primitive-0.8.0.0_1.cabal;textproc/pandoc:hackage/isocline-1.0.9.tar.gz;textproc/pandoc:hackage/dec-0.0.5_1.cabal;productivity/hledger:hackage/base-orphans-0.9.0.tar.gz;textproc/pandoc:hackage/unicode-collation-0.1.3.5.tar.gz;devel/git-annex:hackage/data-default-instances-old-locale-0.0.1.tar.gz;productivity/hledger:hackage/typed-process-0.2.11.0.tar.gz;productivity/hledger:hackage/network-3.1.4.0_1.cabal;textproc/pandoc:hackage/time-manager-0.0.1.tar.gz;textproc/pandoc:hackage/http-client-tls-0.3.6.3.tar.gz;devel/darcs:hackage/type-equality-1.tar.gz;productivity/hledger:hackage/th-compat-0.1.4_3.cabal;textproc/pandoc:hackage/hslua-core-2.3.1.tar.gz;devel/git-annex:hackage/bsb-http-chunked-0.0.0.4_3.cabal;textproc/pandoc:hackage/pandoc-lua-marshal-0.2.2.tar.gz;textproc/pandoc:hackage/base64-0.4.2.4_3.cabal;textproc/pandoc:hackage/http-media-0.8.1.1.tar.gz;devel/cabal-bundler:hackage/distributive-0.6.2.1_1.cabal;productivity/hledger:hackage/regex-tdfa-1.3.2.2.tar.gz;productivity/hledger:hackage/ansi-terminal-types-0.11.5.tar.gz;devel/git-annex:hackage/word8-0.1.3.tar.gz;textproc/pandoc:hackage/dec-0.0.5.tar.gz;productivity/hledger:hackage/dlist-1.0_1.cabal;textproc/pandoc:hackage/base64-bytestring-1.2.1.0_1.cabal;devel/darcs:hackage/monad-control-1.0.3.1.tar.gz;devel/cabal-bundler:hackage/contravariant-1.5.5.tar.gz;devel/darcs:hackage/call-stack-0.4.0.tar.gz;devel/cabal-bundler:hackage/Glob-0.10.2.tar.gz;productivity/hledger:hackage/ansi-terminal-1.0.tar.gz;textproc/pandoc:hackage/boring-0.2.1.tar.gz;productivity/hledger:hackage/text-iso8601-0.1.tar.gz;productivity/hledger:hackage/blaze-html-0.9.1.2_4.cabal;textproc/pandoc:hackage/http-client-0.7.14.tar.gz;textproc/pandoc:hackage/commonmark-pandoc-0.2.1.3.tar.gz;devel/darcs:hackage/old-time-1.1.0.3.tar.gz;productivity/hledger:hackage/integer-conversion-0.1.tar.gz;devel/cabal-install:hackage/zlib-0.6.3.0.tar.gz;productivity/hledger:hackage/bifunctors-5.6.1.tar.gz;productivity/hledger:hackage/mmorph-1.2.0.tar.gz;textproc/pandoc:hackage/JuicyPixels-3.3.8.tar.gz;textproc/pandoc:hackage/wai-app-static-3.1.8.tar.gz;productivity/hledger:hackage/optparse-applicative-0.18.1.0.tar.gz;textproc/pandoc:hackage/wai-cors-0.2.7.tar.gz;productivity/hledger:hackage/regex-base-0.94.0.2_2.cabal;textproc/pandoc:hackage/type-equality-1_5.cabal;devel/git-annex:hackage/vault-0.3.1.5.tar.gz;devel/cabal-bundler:hackage/comonad-5.0.8.tar.gz;devel/cabal-install:hackage/base64-bytestring-1.2.1.0.t

Re: [maintainer update] pandoc 3.1.8

[Greg Steuck]

Hi Evan,

Evan Silberman  writes:

> Hi Greg, ports,
>
> Straightforward upgrade of Pandoc to 3.1.8 from a couple weeks ago,
> hoping to go in before ports freeze. (I only sit down to do this every
> so often so I was sort of playing chicken with the release cycle in case
> there was a bugfix release shortly after 3.1.8 here)

Thank you, I minimally tested the package and committed it.

> Among the changes since 3.1.6.1 here are improvements to the man(7)
> writer mode that benefitted from the input of OpenBSD and mandoc's very
> own Ingo Schwarze, see https://github.com/jgm/pandoc/issues/9020. Thanks
> for bringing your knowledge, generosity, and patience to bear on this
> one Ingo!

Yeah, thanks Ingo, this is quite impressive!

Thanks
Greg

[maintainer update] pandoc 3.1.8

[Evan Silberman]

Hi Greg, ports,

Straightforward upgrade of Pandoc to 3.1.8 from a couple weeks ago,
hoping to go in before ports freeze. (I only sit down to do this every
so often so I was sort of playing chicken with the release cycle in case
there was a bugfix release shortly after 3.1.8 here)

Among the changes since 3.1.6.1 here are improvements to the man(7)
writer mode that benefitted from the input of OpenBSD and mandoc's very
own Ingo Schwarze, see https://github.com/jgm/pandoc/issues/9020. Thanks
for bringing your knowledge, generosity, and patience to bear on this
one Ingo!

Evan


diff /usr/ports
commit - 15b8c3090611bf0a7324e791b1f38bd48923fedd
path + /usr/ports
blob - a0f721cb8cd4666862ea70a8d4a0761d1d86c90e
file + textproc/pandoc/Makefile
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -1,4 +1,4 @@
-V =3.1.6.1
+V =3.1.8
 COMMENT =  convert between markup and document formats
 PKGNAME =  pandoc-${V}
 
@@ -29,6 +29,7 @@ MODCABAL_EXECUTABLES =pandoc
 post-install:
${INSTALL_MAN} ${WRKDIR}/${PKGNAME}/man/pandoc.1 ${PREFIX}/man/man1
 
+
 MODCABAL_MANIFEST  = \
Glob0.10.2  3   \
HUnit   1.6.2.0 0   \
@@ -50,7 +51,6 @@ MODCABAL_MANIFEST = \
assoc   1.1 0   \
async   2.2.4   3   \
attoparsec  0.14.4  4   \
-   attoparsec-iso8601  1.1.0.0 1   \
auto-update 0.1.6   0   \
base-compat 0.13.0  0   \
base-compat-batteries   0.13.0  0   \
@@ -61,22 +61,22 @@ MODCABAL_MANIFEST   = \
base64-bytestring   1.2.1.0 1   \
basement0.0.16  0   \
bifunctors  5.6.1   1   \
-   bitvec  1.1.4.0 0   \
-   blaze-builder   0.4.2.2 1   \
-   blaze-html  0.9.1.2 3   \
-   blaze-markup0.8.2.8 5   \
+   bitvec  1.1.5.0 0   \
+   blaze-builder   0.4.2.3 0   \
+   blaze-html  0.9.1.2 4   \
+   blaze-markup0.8.3.0 0   \
boring  0.2.1   0   \
bsb-http-chunked0.0.0.4 3   \
byteorder   1.0.4   0   \
cabal-doctest   1.0.9   3   \
call-stack  0.4.0   0   \
case-insensitive1.2.1.0 0   \
-   cassava 0.5.3.0 3   \
+   cassava 0.5.3.0 4   \
cereal  0.5.8.3 0   \
citeproc0.8.1   0   \
colour  2.3.6   0   \
commonmark  0.2.3   0   \
-   commonmark-extensions   0.2.3.5 0   \
+   commonmark-extensions   0.2.3.6 0   \
commonmark-pandoc   0.2.1.3 0   \
comonad 5.0.8   1   \
conduit 1.3.5   0   \
@@ -90,7 +90,6 @@ MODCABAL_MANIFEST = \
crypton-x509-store  1.6.9   0   \
crypton-x509-system 1.6.7   0   \
crypton-x509-validation 1.6.12  0   \
-   cryptonite  0.300   \
data-array-byte 0.1.0.1 1   \
data-default0.7.1.1 0   \
data-default-class  0.1.2.0 0   \
@@ -99,10 +98,10 @@ MODCABAL_MANIFEST   = \
data-default-instances-old-locale   0.0.1   0   \
data-fix0.3.2   4   \
dec 0.0.5   1   \
-   digest  0.0.1.7 0   \
+   digest  0.0.1.7 1   \
digits  0.3.1   0   \
distributive0.6.2.1 1   \
-   dlist   1.0 0   \
+   dlist   1.0 1   \
doclayout   0.4.0.1 0   \
doctemplates0.110   \
easy-file   0.2.5   0   \
@@ -117,7 +116,7 @@ MODCABAL_MANIFEST   = \
hashable1.4.3.0 0   \
haskell-lexer   1.1.1   0   \
hourglass   0.2.12  0   \
-   hsc2hs  0.68.9  0   \
+   hsc2hs  0.68.10 0   \
hslua   2.3.0   0   \
hslua-aeson 2.3.0.1 0   \
hslua-classes   2.3.0   0   \
@@ -135,15 +134,16 @@ MODCABAL_MANIFEST = \
hslua-packaging 2.3.0   0   \
hslua-repl  0.1.1   0   \
hslua-typing0.1.0   0   \
-   http-api-data   0.5.1   0   \
-   http-client 0.7.13.11   \
-   http-client-tls 0.3.6.2 0   \
+   http-api-data   0.6 0   \
+   http-client 0.7.14  0   \
+   http-client-tls 0.3.6.3 0   \
http-date   0.0.11  0   \
-   http-media  0.8.0.0 8   \
+   http-media  0.8.1.1 0   \
http-types  0.12.3  0   \
-   http2   4.1.4   0   \
+   http2   4.2.0   0   \
indexed-traversable 0.1.2.1 0   \
indexed-traversable-instances   0.1.1.2 1   \
+   integer-conversion  0.1 0   \
integer-logarithms  1.0.3.1 4   \
iproute 1.7.12  0   \
ipynb   0.2 1   \
@@ -164,35 +164,35 @@ MODCABAL_MANIFEST = \
old-time

Re: Update pandoc to 3.1.6.1

[Greg Steuck]

Evan Silberman  writes:

> Greg Steuck  wrote:
>> Looks like `pandoc lua` doesn't require and runtime deps on lua,
>> is that correct?
>
> Correct. HsLua embeds a Lua interpreter by default. NB the embedded Lua
> existed before 3.x for custom filters there just wasn't the option to
> run pandoc in Lua repl mode, so nothing new here. We can configure our
> build to link to a system-installed Lua. I don't know of a particular
> reason to do so.

Nor do I. Let's commit it as is. Thanks for the update.

Thanks
Grg

Re: Update pandoc to 3.1.6.1

[Evan Silberman]

Greg Steuck  wrote:
> Looks like `pandoc lua` doesn't require and runtime deps on lua,
> is that correct?

Correct. HsLua embeds a Lua interpreter by default. NB the embedded Lua
existed before 3.x for custom filters there just wasn't the option to
run pandoc in Lua repl mode, so nothing new here. We can configure our
build to link to a system-installed Lua. I don't know of a particular
reason to do so.

Evan

Re: Update pandoc to 3.1.6.1

[Greg Steuck]

Thanks for the update Evan! I was not eager to do it due to the -cli
changes, so I appreciate your taking care of it.

I tested your diff with net/gssdp (which seems like the only BUILD_DEPS
user of pandoc). Then also ran a manual step of shellcheck to confirm
the new version produces something sensible. AFAICT, the update is good
to go in. I have just a minor clarifying question below before I commit.

Evan Silberman  writes:

> Hi Greg, ports@
>
> The below updates pandoc to this week's 3.1.6.1. Sorry for the lax
> maintainership! I should be a bit more regular with these now.
>
> The command line tool is now built from the pandoc-cli cabal module,
> which has its own versioning, so things are a little less tidy in the
> Makefile now, oh well. The big developments in version 3 were the
> `pandoc lua` and `pandoc server` modes, which start up into a Lua
> interpreter and an HTTP server respectively. Both modes seem to
> function, or at least execute properly.

Looks like `pandoc lua` doesn't require and runtime deps on lua,
is that correct?

Thanks
Greg

Update pandoc to 3.1.6.1

[Evan Silberman]

Hi Greg, ports@

The below updates pandoc to this week's 3.1.6.1. Sorry for the lax
maintainership! I should be a bit more regular with these now.

The command line tool is now built from the pandoc-cli cabal module,
which has its own versioning, so things are a little less tidy in the
Makefile now, oh well. The big developments in version 3 were the
`pandoc lua` and `pandoc server` modes, which start up into a Lua
interpreter and an HTTP server respectively. Both modes seem to
function, or at least execute properly.

Evan

diff /usr/ports
commit - 608ee79557055c2e8af86b28bd27976cfc65442b
path + /usr/ports
blob - 42305e6437b48cfff88a3238129650f7190d5175
file + textproc/pandoc/Makefile
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -1,6 +1,6 @@
-
+V =3.1.6.1
 COMMENT =  convert between markup and document formats
-REVISION = 0
+PKGNAME =  pandoc-${V}
 
 CATEGORIES =   converters textproc
 
@@ -22,212 +22,237 @@ MODCABAL_STEM =   pandoc
 
 MODULES =  devel/cabal
 MODCABAL_FLAGS =   embed_data_files
-MODCABAL_STEM =pandoc
-MODCABAL_VERSION = 2.19.2
+MODCABAL_STEM =pandoc-cli
+MODCABAL_VERSION = 0.1.1.1
+MODCABAL_EXECUTABLES = pandoc
 
-# Avoids cloning from github
-post-extract:
-   @rm ${WRKSRC}/cabal.project
-
 post-install:
-   ${INSTALL_MAN} ${WRKSRC}/man/pandoc.1 ${PREFIX}/man/man1
+   ${INSTALL_MAN} ${WRKDIR}/${PKGNAME}/man/pandoc.1 ${PREFIX}/man/man1
 
 MODCABAL_MANIFEST  = \
Glob0.10.2  3   \
HUnit   1.6.2.0 0   \
-   HsYAML  0.2.1.1 1   \
JuicyPixels 3.3.8   0   \
-   OneTuple0.3.1   3   \
-   QuickCheck  2.14.2  0   \
+   OneTuple0.4.1.1 0   \
+   Only0.1 2   \
+   QuickCheck  2.14.3  0   \
SHA 1.6.4.4 0   \
StateVar1.2.2   0   \
-   aeson   2.1.0.0 2   \
-   aeson-pretty0.8.9   2   \
-   ansi-terminal   0.11.3  0   \
-   ansi-wl-pprint  0.6.9   3   \
+   aeson   2.1.2.1 3   \
+   aeson-pretty0.8.10  0   \
+   alex3.4.0.0 0   \
+   ansi-terminal   1.0 0   \
+   ansi-terminal-types 0.11.5  1   \
appar   0.1.8   0   \
asn1-encoding   0.9.6   2   \
asn1-parse  0.9.5   0   \
asn1-types  0.3.4   0   \
-   assoc   1.0.2   3   \
-   async   2.2.4   2   \
-   attoparsec  0.14.4  2   \
-   attoparsec-iso8601  1.0.2.1 0   \
+   assoc   1.1 0   \
+   async   2.2.4   3   \
+   attoparsec  0.14.4  4   \
+   attoparsec-iso8601  1.1.0.0 1   \
auto-update 0.1.6   0   \
-   base-compat 0.12.2  0   \
-   base-compat-batteries   0.12.2  0   \
-   base-orphans0.8.7   0   \
+   base-compat 0.13.0  0   \
+   base-compat-batteries   0.13.0  0   \
+   base-orphans0.9.0   0   \
+   base-unicode-symbols0.2.4.2 0   \
base16-bytestring   1.0.2.0 0   \
-   base64  0.4.2.4 1   \
-   base64-bytestring   1.2.1.0 0   \
-   basement0.0.15  0   \
-   bifunctors  5.5.12  1   \
-   bitvec  1.1.3.0 0   \
+   base64  0.4.2.4 3   \
+   base64-bytestring   1.2.1.0 1   \
+   basement0.0.16  0   \
+   bifunctors  5.6.1   1   \
+   bitvec  1.1.4.0 0   \
blaze-builder   0.4.2.2 1   \
-   blaze-html  0.9.1.2 2   \
-   blaze-markup0.8.2.8 3   \
-   boring  0.2 2   \
+   blaze-html  0.9.1.2 3   \
+   blaze-markup0.8.2.8 5   \
+   boring  0.2.1   0   \
bsb-http-chunked0.0.0.4 3   \
byteorder   1.0.4   0   \
-   cabal-doctest   1.0.9   2   \
+   cabal-doctest   1.0.9   3   \
call-stack  0.4.0   0   \
case-insensitive1.2.1.0 0   \
+   cassava 0.5.3.0 3   \
cereal  0.5.8.3 0   \
-   citeproc0.8.0.1 0   \
+   citeproc0.8.1   0   \
colour  2.3.6   0   \
-   commonmark  0.2.2   0   \
-   commonmark-extensions   0.2.3.2 0   \
-   commonmark-pandoc   0.2.1.2 0   \
+   commonmark  0.2.3   0   \
+   commonmark-extensions   0.2.3.5 0   \
+   commonmark-pandoc   0.2.1.3 0   \
comonad 5.0.8   1   \
-   conduit 1.3.4.2 0   \
+   conduit 1.3.5   0   \
conduit-extra   1.3.6   0   \
-   connection  0.3.1   1   \
-   constraints 0.13.4  0   \
+   constraints 0.13.4  1   \
contravariant   1.5.5   0   \
-   cookie  0.4.5   0   \
+   cookie  0.4.6   0

Re: PORT textproc/pandoc broken due to out of memory fix /etc/login.conf

[Phil Maker]

Ack,

Its always fun playing with ports so sorry for not understanding the ghc
thing.

Ta

On Mon, Aug 1, 2022 at 6:00 PM Stuart Henderson  wrote:

> On 2022/08/01 13:10, Phil Maker wrote:
> > G'day,
> >
> > Port  textproc/pandoc indicates it is broken with  a ghc out of memory
> error
> > setting at top of the Makefile, and I think that the mainainer isn't a
> > person but here.
> > So the Makefile
> >
> >
> > *# Even with the highest memory limit pandoc fails to
> compile.BROKEN-i386 =
> >   ghc: out of memory (requested 2097152 bytes)*
> >
> > Increasing the datasize-max and datasize-cur by 2Mb in /etc/login.conf
> > fixes the problem, for example:
>
> It didn't when I added the BROKEN marker, I was attempting with no limit
> in login.conf.
>
> The point is moot now anyway, as lang/ghc is no longer built on i386.
>
>

-- 
Phil Maker
web: https://eds.power.on.net/EDS
email: 
phoneemail:  -- email to phone (fastest)
phone: +61 (0)447 630 229
Nicknames: bung, browndog, uncle, chippy.

"fain (feɪn) Archaic. adv. 1. gladly; willingly: He fain would accept"
"obrigado: I am obligated"


"The inability to isolate software components from each other is the main
reason why many popular programming languages cannot be used for making
robust system software." -- Joe Armstrong

Re: PORT textproc/pandoc broken due to out of memory fix /etc/login.conf

[Stuart Henderson]

On 2022/08/01 13:10, Phil Maker wrote:
> G'day,
> 
> Port  textproc/pandoc indicates it is broken with  a ghc out of memory error
> setting at top of the Makefile, and I think that the mainainer isn't a
> person but here.
> So the Makefile
> 
> 
> *# Even with the highest memory limit pandoc fails to compile.BROKEN-i386 =
>   ghc: out of memory (requested 2097152 bytes)*
> 
> Increasing the datasize-max and datasize-cur by 2Mb in /etc/login.conf
> fixes the problem, for example:

It didn't when I added the BROKEN marker, I was attempting with no limit
in login.conf.

The point is moot now anyway, as lang/ghc is no longer built on i386. 

PORT textproc/pandoc broken due to out of memory fix /etc/login.conf

[Phil Maker]

G'day,

Port  textproc/pandoc indicates it is broken with  a ghc out of memory error
setting at top of the Makefile, and I think that the mainainer isn't a
person but here.
So the Makefile


*# Even with the highest memory limit pandoc fails to compile.BROKEN-i386 =
  ghc: out of memory (requested 2097152 bytes)*

Increasing the datasize-max and datasize-cur by 2Mb in /etc/login.conf
fixes the problem, for example:













*default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin
/usr/local/bin /usr/local/sbin:\ :umask=022:\ :datasize-max=2768M:\
:datasize-cur=2768M:\ :maxproc-max=256:\ :maxproc-cur=128:\
:openfiles-max=1024:\ :openfiles-cur=512:\ :stacksize-cur=4M:\
:localcipher=blowfish,a:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults:*

Now clearly that is a bat shit crazy amount of store, so maybe we do one of:

1. Change the error message to indicate you should/may increase datasize*
in /etc/login.conf
2. Change the default system login.conf (but that seems unusual and a bit
risky). This is that tail wagging
the dog, etc. Still I'm surprised that everything in /usr/local/bin has
a datasize limited 768M given the
bloatware.

Ta
-- 
Phil Maker
web: https://eds.power.on.net/EDS
email: 
phoneemail:  -- email to phone (fastest)
phone: +61 (0)447 630 229
Nicknames: bung, browndog, uncle, chippy.

"fain (feɪn) Archaic. adv. 1. gladly; willingly: He fain would accept"
"obrigado: I am obligated"


"The inability to isolate software components from each other is the main
reason why many popular programming languages cannot be used for making
robust system software." -- Joe Armstrong

Re: Update pandoc to 2.18

[Evan Silberman]

Greg Steuck  wrote:
> Hi Evan,
> 
> Evan Silberman  writes:
> 
> > Attached updates pandoc to 2.18, also takes maintainer. (I finally have
> > openbsd on a laptop after a couple years of debating with myself how
> > sensible it is to buy yet another laptop.)
> 
> Very nice, thank you for taking the initiative and upgrading the port.
> I'm ready to commit your patch. I just would like to confirm if you ran
> some tests with the new package version.

Yes, can convert pandoc's manual from markdown to docx to ReStructured
Text to epub to LaTeX without errors.
> 
> > I know a new GHC version is cooking so maybe it doesn't make sense to
> > commit this now, but maybe that doesn't really matter either.
> 
> I checked that your port is buildable with ghc-9.2.2. So it's good to go.
> 

Sweet.

Evan

Re: Update pandoc to 2.18

[Greg Steuck]

Hi Evan,

Evan Silberman  writes:

> Attached updates pandoc to 2.18, also takes maintainer. (I finally have
> openbsd on a laptop after a couple years of debating with myself how
> sensible it is to buy yet another laptop.)

Very nice, thank you for taking the initiative and upgrading the port.
I'm ready to commit your patch. I just would like to confirm if you ran
some tests with the new package version.

> I know a new GHC version is cooking so maybe it doesn't make sense to
> commit this now, but maybe that doesn't really matter either.

I checked that your port is buildable with ghc-9.2.2. So it's good to go.

Thanks
Greg

Update pandoc to 2.18

[Evan Silberman]

Hi Greg and ports,

Attached updates pandoc to 2.18, also takes maintainer. (I finally have
openbsd on a laptop after a couple years of debating with myself how
sensible it is to buy yet another laptop.)

I know a new GHC version is cooking so maybe it doesn't make sense to
commit this now, but maybe that doesn't really matter either.

Thanks,
Evan Silberman
diff 3a5576332764e1c2f234d1efab1c924b18c01d81 /usr/ports
blob - 1030963cdb78602503e7c9c2ebc65ee203afe4a5
file + textproc/pandoc/Makefile
--- textproc/pandoc/Makefile
+++ textproc/pandoc/Makefile
@@ -7,6 +7,8 @@ CATEGORIES =converters textproc
 
 HOMEPAGE = https://pandoc.org
 
+MAINTAINER =   Evan Silberman 
+
 # GPLv2+
 PERMIT_PACKAGE =   Yes
 
@@ -22,7 +24,7 @@ NO_TEST = Yes
 MODULES =  devel/cabal
 MODCABAL_FLAGS =   embed_data_files
 MODCABAL_STEM =pandoc
-MODCABAL_VERSION = 2.17.1.1
+MODCABAL_VERSION = 2.18
 
 # Avoids cloning from github
 post-extract:
@@ -63,10 +65,10 @@ MODCABAL_MANIFEST   = \
cabal-doctest   1.0.9   0   \
case-insensitive1.2.1.0 0   \
cereal  0.5.8.2 0   \
-   citeproc0.6.0.1 0   \
+   citeproc0.7 0   \
colour  2.3.6   0   \
-   commonmark  0.2.1.1 0   \
-   commonmark-extensions   0.2.3   0   \
+   commonmark  0.2.2   0   \
+   commonmark-extensions   0.2.3.1 0   \
commonmark-pandoc   0.2.1.2 0   \
comonad 5.0.8   1   \
conduit 1.3.4.2 0   \
@@ -84,8 +86,8 @@ MODCABAL_MANIFEST = \
digest  0.0.1.3 0   \
distributive0.6.2.1 1   \
dlist   1.0 0   \
-   doclayout   0.3.1.1 0   \
-   doctemplates0.10.0.10   \
+   doclayout   0.4 0   \
+   doctemplates0.10.0.20   \
emojis  0.1.2   0   \
errors  2.3.0   2   \
file-embed  0.0.15.00   \
@@ -95,17 +97,18 @@ MODCABAL_MANIFEST   = \
haskell-lexer   1.1 0   \
hourglass   0.2.12  0   \
hsc2hs  0.68.8  0   \
-   hslua   2.1.0   0   \
-   hslua-aeson 2.1.0   0   \
-   hslua-classes   2.1.0   0   \
-   hslua-core  2.1.0   0   \
-   hslua-marshalling   2.1.0   0   \
+   hslua   2.2.0   0   \
+   hslua-aeson 2.2.0   0   \
+   hslua-classes   2.2.0   0   \
+   hslua-core  2.2.0   0   \
+   hslua-marshalling   2.2.0   0   \
+   hslua-module-doclayout  1.0.4   0   \
hslua-module-path   1.0.2   0   \
hslua-module-system 1.0.2   0   \
hslua-module-text   1.0.2   0   \
hslua-module-version1.0.2   0   \
-   hslua-objectorientation 2.1.0   0   \
-   hslua-packaging 2.1.0   0   \
+   hslua-objectorientation 2.2.0   0   \
+   hslua-packaging 2.2.0   0   \
http-client 0.7.11  1   \
http-client-tls 0.3.6.1 0   \
http-types  0.12.3  0   \
@@ -117,7 +120,7 @@ MODCABAL_MANIFEST   = \
jira-wiki-markup1.4.0   0   \
libyaml 0.1.2   0   \
lpeg1.0.3   0   \
-   lua 2.1.0   0   \
+   lua 2.2.0   0   \
memory  0.17.0  0   \
mime-types  0.1.0.9 0   \
mono-traversable1.0.15.30   \
@@ -125,7 +128,7 @@ MODCABAL_MANIFEST   = \
network-uri 2.6.4.1 0   \
old-locale  1.0.0.7 2   \
pandoc-lua-marshal  0.1.5.1 0   \
-   pandoc-types1.22.1  0   \
+   pandoc-types1.22.2  0   \
pem 0.2.4   0   \
pretty-show 1.100   \
primitive   0.7.3.0 0   \
@@ -146,7 +149,7 @@ MODCABAL_MANIFEST   = \
tagged  0.8.6.1 2   \
tagsoup 0.14.8  0   \
temporary   1.3 0   \
-   texmath 0.12.4  0   \
+   texmath 0.12.5  0   \
text-conversions0.3.1   0   \
text-short  0.1.5   0   \
th-abstraction  0.4.3.0 0   \
@@ -163,7 +166,7 @@ MODCABAL_MANIFEST   = \
unicode-transforms  0.4.0.1 0   \
uniplate1.6.13  1   \
unliftio-core   0.2.0.1 2   \
-   unordered-containers0.2.17.00   \
+   unordered-containers0.2.19.10   \
utf8-string 1.0.2   0   \
uuid-types  1.0.5   2   \
vector  0.12.3.11   \
blob - 1b901f1bb439861ce6becc031b2216e1e5ed91b4
file + textproc/pandoc/distinfo
--- textproc/pandoc/distinfo
+++ textproc/pandoc/distinfo
@@ -42,10 +42,10 @@ SHA256 (hackage/byteorder-1.0.4.tar.gz) = vSC7tYaUf5nD
 SHA256 (hackage/cabal-doctest-1.0.9.tar.gz

[PATCH] Upgrade textproc/pandoc 2.14.2->2.16.1

[Greg Steuck]

Courtesy of cabal-bundler. Confirmed to install and shows --version.

OK?

>From b6aad35fb752de7df3f44b5ba827699686db9157 Mon Sep 17 00:00:00 2001
From: Greg Steuck 
Date: Wed, 17 Nov 2021 22:43:35 -0800
Subject: [PATCH] Upgrade textproc/pandoc 2.14.2->2.16.1

---
 textproc/pandoc/Makefile | 116 ++
 textproc/pandoc/distinfo | 252 ---
 2 files changed, 222 insertions(+), 146 deletions(-)

diff --git a/textproc/pandoc/Makefile b/textproc/pandoc/Makefile
index a52239f334f..fcac7df7d77 100644
--- a/textproc/pandoc/Makefile
+++ b/textproc/pandoc/Makefile
@@ -24,7 +24,7 @@ NO_TEST = Yes
 MODULES =  devel/cabal
 MODCABAL_FLAGS =   embed_data_files
 MODCABAL_STEM =    pandoc
-MODCABAL_VERSION = 2.14.2
+MODCABAL_VERSION = 2.16.1
 
 # Avoids cloning from github
 post-extract:
@@ -33,45 +33,48 @@ post-extract:
 post-install:
${INSTALL_MAN} ${WRKSRC}/man/pandoc.1 ${PREFIX}/man/man1
 
-MODCABAL_MANIFEST = \
-   Glob0.10.1  1   \
-   HsYAML  0.2.1.0 2   \
+MODCABAL_MANIFEST  = \
+   Glob0.10.2  1   \
+   HsYAML  0.2.1.0 3   \
JuicyPixels 3.3.6   0   \
+   OneTuple0.3.1   2   \
QuickCheck  2.14.2  0   \
SHA 1.6.4.4 0   \
-   aeson   1.5.6.0 2   \
-   aeson-pretty0.8.8   1   \
+   StateVar1.2.2   0   \
+   aeson   2.0.2.0 0   \
+   aeson-pretty0.8.9   1   \
ansi-terminal   0.110   \
appar   0.1.8   0   \
asn1-encoding   0.9.6   2   \
asn1-parse  0.9.5   0   \
asn1-types  0.3.4   0   \
-   assoc   1.0.2   1   \
-   async   2.2.4   0   \
-   attoparsec  0.14.1  0   \
-   base-compat 0.12.0  0   \
-   base-compat-batteries   0.12.0  1   \
-   base-orphans0.8.5   0   \
-   base16-bytestring   1.0.1.0 0   \
+   assoc   1.0.2   2   \
+   async   2.2.4   1   \
+   attoparsec  0.14.2  1   \
+   base-compat 0.12.1  0   \
+   base-compat-batteries   0.12.1  1   \
+   base-orphans0.8.6   0   \
+   base16-bytestring   1.0.2.0 0   \
base64-bytestring   1.2.1.0 0   \
basement0.0.12  1   \
bifunctors  5.5.11  1   \
-   blaze-builder   0.4.2.1 0   \
+   blaze-builder   0.4.2.2 0   \
blaze-html  0.9.1.2 1   \
-   blaze-markup0.8.2.8 0   \
+   blaze-markup0.8.2.8 1   \
byteorder   1.0.4   0   \
-   cabal-doctest   1.0.8   2   \
+   cabal-doctest   1.0.9   0   \
case-insensitive1.2.1.0 0   \
-   cereal  0.5.8.1 1   \
-   citeproc0.5 0   \
+   cereal  0.5.8.2 0   \
+   citeproc0.6 0   \
colour  2.3.6   0   \
-   commonmark  0.2.1   0   \
-   commonmark-extensions   0.2.1.2 0   \
+   commonmark  0.2.1.1 0   \
+   commonmark-extensions   0.2.2.1 0   \
commonmark-pandoc   0.2.1.1 0   \
comonad 5.0.8   1   \
conduit 1.3.4.2 0   \
conduit-extra   1.3.5   0   \
connection  0.3.1   1   \
+   contravariant   1.5.5   0   \
cookie  0.4.5   0   \
cryptonite  0.290   \
data-default0.7.1.1 0   \
@@ -79,7 +82,7 @@ MODCABAL_MANIFEST = \
data-default-instances-containers   0.0.1   0   \
data-default-instances-dlist0.0.1   0   \
data-default-instances-old-locale   0.0.1   0   \
-   data-fix0.3.2   0   \
+   data-fix0.3.2   2   \
digest  0.0.1.3 0   \
distributive0.6.2.1 1   \
dlist   1.0 0   \
@@ -89,66 +92,82 @@ MODCABAL_MANIFEST = \
errors  2.3.0   1   \
file-embed  0.0.15.00   \
haddock-library 1.10.0  1   \
-   hashable1.3.4.1 0   \
+   happy   1.20.0  0   \
+   hashable1.4.0.0 0   \
+   haskell-lexer   1.1 0   \
hourglass   0.2.12  0   \
-   hsc2hs  0.68.7  1   \
-   hslua   1.3.0.2 0   \
-   hslua-module-path   0.1.0.1 0   \
-   hslua-module-system 0.2.2.1 0   \
-   hslua-module-text   0.3.0.1 1   \
+   hsc2hs  0.68.8  0   \
+   hslua   2.0.1   0   \
+   hslua-classes   2.0.0   0   \
+   hslua-core  2.0.0.2 0   \
+   hslua-marshalling   2.0.1   0   \
+   hslua-module-path   1.0.0   0   \
+   hslua-module-system 1.0.0   0   \
+   hslua-module-text   1.0.0   0   \
+   hslua-module-version1.0

[PATCH 5/9] Upgrade textproc/pandoc 2.12->2.14.2

[Greg Steuck]

Confirmed that it can do a trivial .html->.md conversion. I don't really
use pandoc, so people who care should test.

OK?

>From 71b0de43626dbd9427957ccea6153c4558f2fb56 Mon Sep 17 00:00:00 2001
From: Greg Steuck 
Date: Sun, 17 Oct 2021 19:26:02 -0700
Subject: [PATCH 5/9] Upgrade textproc/pandoc 2.12->2.14.2

---
 textproc/pandoc/Makefile | 137 ++--
 textproc/pandoc/distinfo | 274 ++-
 2 files changed, 223 insertions(+), 188 deletions(-)

diff --git a/textproc/pandoc/Makefile b/textproc/pandoc/Makefile
index c5c948477aa..fc8b8e35e28 100644
--- a/textproc/pandoc/Makefile
+++ b/textproc/pandoc/Makefile
@@ -24,7 +24,7 @@ NO_TEST = Yes
 MODULES =  devel/cabal
 MODCABAL_FLAGS =   embed_data_files
 MODCABAL_STEM =        pandoc
-MODCABAL_VERSION = 2.12
+MODCABAL_VERSION = 2.14.2
 
 # Avoids cloning from github
 post-extract:
@@ -34,124 +34,129 @@ post-install:
${INSTALL_MAN} ${WRKSRC}/man/pandoc.1 ${PREFIX}/man/man1
 
 MODCABAL_MANIFEST = \
-   Glob0.10.1  0   \
-   HTTP4000.3.15   2   \
+   Glob0.10.1  1   \
HsYAML  0.2.1.0 2   \
-   JuicyPixels 3.3.5   0   \
+   JuicyPixels 3.3.6   0   \
QuickCheck  2.14.2  0   \
SHA 1.6.4.4 0   \
-   aeson   1.5.6.0 0   \
-   aeson-pretty0.8.8   0   \
+   aeson   1.5.6.0 2   \
+   aeson-pretty0.8.8   1   \
ansi-terminal   0.110   \
+   appar   0.1.8   0   \
asn1-encoding   0.9.6   2   \
asn1-parse  0.9.5   0   \
asn1-types  0.3.4   0   \
assoc   1.0.2   1   \
-   async   2.2.3   0   \
-   attoparsec  0.13.2.51   \
-   base-compat 0.11.2  0   \
-   base-compat-batteries   0.11.2  0   \
-   base-orphans0.8.4   0   \
+   async   2.2.4   0   \
+   attoparsec  0.14.1  0   \
+   base-compat 0.12.0  0   \
+   base-compat-batteries   0.12.0  1   \
+   base-orphans0.8.5   0   \
base16-bytestring   1.0.1.0 0   \
-   base64-bytestring   1.2.0.1 0   \
-   basement0.0.11  3   \
-   bifunctors  5.5.10  0   \
+   base64-bytestring   1.2.1.0 0   \
+   basement0.0.12  1   \
+   bifunctors  5.5.11  1   \
blaze-builder   0.4.2.1 0   \
blaze-html  0.9.1.2 1   \
blaze-markup0.8.2.8 0   \
+   byteorder   1.0.4   0   \
cabal-doctest   1.0.8   2   \
case-insensitive1.2.1.0 0   \
-   cereal  0.5.8.1 0   \
-   citeproc0.3.0.9 0   \
-   colour  2.3.5   0   \
-   commonmark  0.1.1.4 0   \
-   commonmark-extensions   0.2.0.4 0   \
-   commonmark-pandoc   0.2.0.1 0   \
-   comonad 5.0.8   0   \
-   conduit 1.3.4.1 0   \
+   cereal  0.5.8.1 1   \
+   citeproc0.5 0   \
+   colour  2.3.6   0   \
+   commonmark  0.2.1   0   \
+   commonmark-extensions   0.2.1.2 0   \
+   commonmark-pandoc   0.2.1.1 0   \
+   comonad 5.0.8   1   \
+   conduit 1.3.4.2 0   \
conduit-extra   1.3.5   0   \
connection  0.3.1   1   \
cookie  0.4.5   0   \
-   cryptonite  0.280   \
+   cryptonite  0.290   \
data-default0.7.1.1 0   \
data-default-class  0.1.2.0 0   \
data-default-instances-containers   0.0.1   0   \
data-default-instances-dlist0.0.1   0   \
data-default-instances-old-locale   0.0.1   0   \
-   data-fix0.3.1   0   \
-   digest  0.0.1.2 0   \
-   distributive0.6.2.1 0   \
+   data-fix0.3.2   0   \
+   digest  0.0.1.3 0   \
+   distributive0.6.2.1 1   \
dlist   1.0 0   \
-   doclayout   0.3 0   \
-   doctemplates0.9 0   \
-   emojis  0.1 0   \
-   errors  2.3.0   0   \
-   file-embed  0.0.13.00   \
-   haddock-library 1.9.0   0   \
-   hashable1.3.1.0 0   \
+   doclayout   0.3.1.1 0   \
+   doctemplates0.10.0.10   \
+   emojis  0.1.2   0   \
+   errors  2.3.0   1   \
+   file-embed  0.0.15.00   \
+   haddock-library 1.10.0  1   \
+   hashable1.3.4.1 0   \
hourglass   0.2.12  0   \
hsc2hs  0.68.7  1   \
-   hslua   1.3.0.1 0   \
+   hslua   1.3.0.2 0   \
hslua-module-path   0.1.0.1 0   \
hslua-module-system 0.2.2.1 0   \
-   hslua-mo

Re: Add pandoc-2.12 via devel/cabal module

[Greg Steuck]

Stuart Henderson  writes:

> Thanks. Updated tar attached, I also installed the manual, moved the
> intereating bits of Makefile above the manifest, and used a more exact license
> marker.
>
> This one is ok with me

Thanks for the prompt review and polishing up the port! Committed now.

Thanks
Greg

Re: Add pandoc-2.12 via devel/cabal module

[Stuart Henderson]

On 2021/03/15 10:25, Aaron Bieber wrote:
> 
> Stuart Henderson writes:
> 
> > On 2021/03/15 08:35, Stuart Henderson wrote:
> >> ===>  Extracting for pandoc-2.12
> >> make: don't know how to make do-extract
> >> Stop in .
> >> 
> >> Do you have something uncommitted in the cabal module?
> >> 
> >
> > Well that's *strange*. It's working now...
> 
> DESCR has some baddies:
> 
> Creating package pandoc-2.12
> DESCR contains weird characters: Pandoc???s enhanced version of Markdown 
> includes syntax for tables, on line 8
> DESCR contains weird characters: Because pandoc???s intermediate 
> representation of a document is less on line 12
> DESCR contains weird characters: such as complex tables, may not fit into 
> pandoc???s simple document model. on line 17
> DESCR contains weird characters: While conversions from pandoc???s Markdown 
> to all formats aspire to be on line 18
> DESCR contains weird characters: perfect, conversions from formats more 
> expressive than pandoc???s Markdown on line 19
> 
> OK abieber@ with that fixed and Stuart's fixes!
> 

Thanks. Updated tar attached, I also installed the manual, moved the
intereating bits of Makefile above the manifest, and used a more exact license
marker.

This one is ok with me



pandoc.tgz
Description: application/tar-gz

Re: Add pandoc-2.12 via devel/cabal module

[Aaron Bieber]

Stuart Henderson writes:

> On 2021/03/15 08:35, Stuart Henderson wrote:
>> ===>  Extracting for pandoc-2.12
>> make: don't know how to make do-extract
>> Stop in .
>> 
>> Do you have something uncommitted in the cabal module?
>> 
>
> Well that's *strange*. It's working now...

DESCR has some baddies:

Creating package pandoc-2.12
DESCR contains weird characters: Pandoc???s enhanced version of Markdown 
includes syntax for tables, on line 8
DESCR contains weird characters: Because pandoc???s intermediate representation 
of a document is less on line 12
DESCR contains weird characters: such as complex tables, may not fit into 
pandoc???s simple document model. on line 17
DESCR contains weird characters: While conversions from pandoc???s Markdown to 
all formats aspire to be on line 18
DESCR contains weird characters: perfect, conversions from formats more 
expressive than pandoc???s Markdown on line 19

OK abieber@ with that fixed and Stuart's fixes!

Re: Add pandoc-2.12 via devel/cabal module

[Stuart Henderson]

On 2021/03/15 08:35, Stuart Henderson wrote:
> ===>  Extracting for pandoc-2.12
> make: don't know how to make do-extract
> Stop in .
> 
> Do you have something uncommitted in the cabal module?
> 

Well that's *strange*. It's working now...

Re: Add pandoc-2.12 via devel/cabal module

[Stuart Henderson]

On 2021/03/14 22:11, Greg Steuck wrote:
> I personally don't have much use for pandoc. If people want to see it in
> 6.9, please test and report back soon. I'd also want somebody's OK.

Definitely good to have this. I've attached a new tar and commented inline
on what I've changed. (tars are much easier to handle than patches for new
ports).

> +# Even with the highest memory limit pandoc fails to compile.
> +BROKEN-i386= ghc: out of memory (requested 2097152 bytes)
> +
> +COMMENT =Conversion between markup formats

lowercase start of comment

> +
> +CATEGORIES = textproc

added converters (maybe that should be the primary category?)

> +HOMEPAGE =   https://pandoc.org
> +
> +# GPL2
> +PERMIT_PACKAGE = Yes
> +
> +WANTLIB =c ffi gmp iconv m pthread util z
> +
> +MODULES =devel/cabal
> +MODCABAL_FLAGS = embed_data_files
> +MODCABAL_STEM= pandoc
> +MODCABAL_VERSION = 2.12
> +MODCABAL_MANIFEST= \

mixture of =, (space)= and (tab)=

> + Glob0.10.1  0   \
..
> +SIZE (hackage/zlib-0.6.2.3.tar.gz) = 149186
> diff --git a/textproc/pandoc/pkg/DESCR b/textproc/pandoc/pkg/DESCR
> new file mode 100644
> index 000..bef1b24a9b1
> --- /dev/null
> +++ b/textproc/pandoc/pkg/DESCR
> @@ -0,0 +1,19 @@
> +Pandoc is a command-line tool for converting from one markup format to
> +another.
> +
> +It can read several dialects of Markdown and
> +(subsets of) HTML, reStructuredText, LaTeX, DocBook, JATS,
> +MediaWiki markup, DokuWiki markup, TWiki markup,
> +TikiWiki markup, Jira markup, Creole 1.0, Haddock markup,

This list of formats is really hard to read and likely to go out of date
easily, I've changed to more of a description of the software and what
it's good for, diverting to the upstream website for the actual formats.

> --- /dev/null
> +++ b/textproc/pandoc/pkg/PLIST
> @@ -0,0 +1,2 @@
> +@comment $OpenBSD: PLIST,v$
> +@bin bin/${MODCABAL_STEM}
> -- 

Oh the irony, no docs! I tried building to see if I could add something but
ran into this main problem, that I haven't fixed:

===>  Extracting for pandoc-2.12
make: don't know how to make do-extract
Stop in .

Do you have something uncommitted in the cabal module?



pandoc.tgz
Description: application/tar-gz

Add pandoc-2.12 via devel/cabal module

[Greg Steuck]

I personally don't have much use for pandoc. If people want to see it in
6.9, please test and report back soon. I'd also want somebody's OK.

Subject: [PATCH] Add pandoc-2.12 via devel/cabal module

Tested on simple md and docx conversions.
Broken and disabled on i386.

diff --git a/textproc/pandoc/Makefile b/textproc/pandoc/Makefile
new file mode 100644
index 000..c3644eecd3f
--- /dev/null
+++ b/textproc/pandoc/Makefile
@@ -0,0 +1,150 @@
+# $OpenBSD$
+
+# Even with the highest memory limit pandoc fails to compile.
+BROKEN-i386=   ghc: out of memory (requested 2097152 bytes)
+
+COMMENT =  Conversion between markup formats
+
+CATEGORIES =   textproc
+
+HOMEPAGE = https://pandoc.org
+
+# GPL2
+PERMIT_PACKAGE =   Yes
+
+WANTLIB =  c ffi gmp iconv m pthread util z
+
+MODULES =  devel/cabal
+MODCABAL_FLAGS =   embed_data_files
+MODCABAL_STEM  = pandoc
+MODCABAL_VERSION   = 2.12
+MODCABAL_MANIFEST  = \
+   Glob0.10.1  0   \
+   HTTP4000.3.15   2   \
+   HsYAML  0.2.1.0 2   \
+   JuicyPixels 3.3.5   0   \
+   QuickCheck  2.14.2  0   \
+   SHA 1.6.4.4 0   \
+   aeson   1.5.6.0 0   \
+   aeson-pretty0.8.8   0   \
+   ansi-terminal   0.110   \
+   asn1-encoding   0.9.6   2   \
+   asn1-parse  0.9.5   0   \
+   asn1-types  0.3.4   0   \
+   assoc   1.0.2   1   \
+   async   2.2.3   0   \
+   attoparsec  0.13.2.51   \
+   base-compat 0.11.2  0   \
+   base-compat-batteries   0.11.2  0   \
+   base-orphans0.8.4   0   \
+   base16-bytestring   1.0.1.0 0   \
+   base64-bytestring   1.2.0.1 0   \
+   basement0.0.11  3   \
+   bifunctors  5.5.10  0   \
+   blaze-builder   0.4.2.1 0   \
+   blaze-html  0.9.1.2 1   \
+   blaze-markup0.8.2.8 0   \
+   cabal-doctest   1.0.8   2   \
+   case-insensitive1.2.1.0 0   \
+   cereal  0.5.8.1 0   \
+   citeproc0.3.0.9 0   \
+   colour  2.3.5   0   \
+   commonmark  0.1.1.4 0   \
+   commonmark-extensions   0.2.0.4 0   \
+   commonmark-pandoc   0.2.0.1 0   \
+   comonad 5.0.8   0   \
+   conduit 1.3.4.1 0   \
+   conduit-extra   1.3.5   0   \
+   connection  0.3.1   1   \
+   cookie  0.4.5   0   \
+   cryptonite  0.280   \
+   data-default0.7.1.1 0   \
+   data-default-class  0.1.2.0 0   \
+   data-default-instances-containers   0.0.1   0   \
+   data-default-instances-dlist0.0.1   0   \
+   data-default-instances-old-locale   0.0.1   0   \
+   data-fix0.3.1   0   \
+   digest  0.0.1.2 0   \
+   distributive0.6.2.1 0   \
+   dlist   1.0 0   \
+   doclayout   0.3 0   \
+   doctemplates0.9 0   \
+   emojis  0.1 0   \
+   errors  2.3.0   0   \
+   file-embed  0.0.13.00   \
+   haddock-library 1.9.0   0   \
+   hashable1.3.1.0 0   \
+   hourglass   0.2.12  0   \
+   hsc2hs  0.68.7  1   \
+   hslua   1.3.0.1 0   \
+   hslua-module-path   0.1.0.1 0   \
+   hslua-module-system 0.2.2.1 0   \
+   hslua-module-text   0.3.0.1 0   \
+   http-client 0.7.6   0   \
+   http-client-tls 0.3.5.3 1   \
+   http-types  0.12.3  0   \
+   indexed-traversable 0.1.1   0   \
+   integer-logarithms  1.0.3.1 0   \
+   ipynb   0.1.0.1 0   \
+   jira-wiki-markup1.3.4   0   \
+   memory  0.15.0  1   \
+   mime-types  0.1.0.9 0   \
+   mono-traversable1.0.15.10   \
+   network 3.1.2.1 1   \
+   network-uri 2.6.4.1 0   \
+   old-locale  1.0.0.7 2   \
+   pandoc-types1.220   \
+   pem 0.2.4   0   \
+   primitive   0.7.1.0 2   \
+   random  1.1 1   \
+   resourcet   1.2.4.2 0   \
+   rfc5051 0.2 0   \
+   safe0.3.19  0   \
+   scientific  0.3.6.2 0   \
+   skylighting 0.10.4  0   \
+   skylighting-core0.10.4  0   \
+   socks   0.6.1   0   \
+   split   0.2.3.4 1   \
+   splitmix0.1.0.3 0   \
+   streaming-commons   0.2.2.1 0   \
+   strict  0.4.0.1 0   \
+   syb 0.7.2.1 0   \
+   tagged  0.8.6.1 0   \
+   tagsoup 0.14.8  0   \
+   temporary   1.3 0   \
+   texmath 0.12.1.10   \
+   text-conversions0.3.1   0   \
+   th-abstraction  0.4.2.0 0

Re: to Pandoc or not

[Marc Espie]

On Wed, Jul 15, 2020 at 05:10:02PM -0700, Evan Silberman wrote:
> Stuart Henderson  wrote:
> > On 2020/07/14 13:23, sven falempin wrote:
> > > Dear readers,
> > > 
> > > Is anyone working on that for openbsd ?
> > > 
> > > https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile
> > > 
> > > I do not know the Cabal build system nor haskell so I have no idea
> > > of the difficulty level of bringing that in ports .
> > > 
> > > IE: is it possible to have it work with just a few tweeks
> > > 
> > > Best,
> > 
> > You maybe able to build it outside of ports by using cabal (see notes at
> > https://marc.info/?l=openbsd-ports=152175625404877=2)
> > 
> > It would be nice to have a package of this, but it's not a beginner-level 
> > thing ;)
> 
> Regarding this, Greg Steuck posted a few weeks ago about working on
> building Haskell ports using cabal-install, which as I understand it
> would be comparable to the way Go and Rust programs are ported. Don't
> think there was any public chatter in response to the proposal though.

I missed that.

I did explicitly refactor portgen a bit so that it would be more accomodating
to things like that.

Seems at some point I'll have to look closer at that piece of code
if it's proving necessary for so many languages :(

seems like we're getting our alien equivalent after all.

Re: to Pandoc or not

[Evan Silberman]

Stuart Henderson  wrote:
> On 2020/07/14 13:23, sven falempin wrote:
> > Dear readers,
> > 
> > Is anyone working on that for openbsd ?
> > 
> > https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile
> > 
> > I do not know the Cabal build system nor haskell so I have no idea
> > of the difficulty level of bringing that in ports .
> > 
> > IE: is it possible to have it work with just a few tweeks
> > 
> > Best,
> 
> You maybe able to build it outside of ports by using cabal (see notes at
> https://marc.info/?l=openbsd-ports=152175625404877=2)
> 
> It would be nice to have a package of this, but it's not a beginner-level 
> thing ;)

Regarding this, Greg Steuck posted a few weeks ago about working on
building Haskell ports using cabal-install, which as I understand it
would be comparable to the way Go and Rust programs are ported. Don't
think there was any public chatter in response to the proposal though.

https://marc.info/?l=openbsd-ports=159337166404423=2

Re: to Pandoc or not

[Ingo Schwarze]

Hi Marc,

Marc Espie wrote on Wed, Jul 15, 2020 at 11:44:32AM +0200:
> On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze wrote:

>> I never found pandoc useful for anything - so much so that i never
>> even felt a need to evalute its quality for real.  I dimly remember
>> that on rare occasions, i saw man(7) output generated by pandoc,
>> and if i remeber correctly, that was of poor quality - but i'm not
>> sure and it isn't terribly relevant because pandoc is used very
>> rarely in practice in the first place.
>> 
>> What do you want to do with it?

> I have colleagues that use pandoc to produce docs, because it's simple
> and heck, they've normalized on it.
> 
> I myself prefer to generate documents straight from LaTeX, but it means
> I can't directly work with them.
> 
> That's most often the situation.
> 
> I would also like a pandoc port.

That does sound fair, and it teaches me that even for things where
it may be hard to come up with a reasonable statement of the form
"it's a good solution to solve problem X", there can indeed be a
good reason to have a port.

Even if "useful to send HTML email" sounds about as oxymoronic to
me as it gets.  =:-o

> There are about 80 haskell dependencies for
> it, none of it is in our ports tree yet.

No way i'm going to help with a beast of that kind, of course.  :)

In the most important port i maintain (also in the textproc category
and useful for documentation), i pay particular attention to make
sure that it never grows a single dependency.  Not even one.

Yours,
  Ingo

Re: to Pandoc or not

[Zé Loff]

On Wed, Jul 15, 2020 at 11:44:32AM +0200, Marc Espie wrote:
> On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
> wrote:
> > I never found pandoc useful for anything - so much so that i never
> > even felt a need to evalute its quality for real.  I dimly remember
> > that on rare occasions, i saw man(7) output generated by pandoc,
> > and if i remeber correctly, that was of poor quality - but i'm not
> > sure and it isn't terribly relevant because pandoc is used very
> > rarely in practice in the first place.
> > 
> > What do you want to do with it?
> 
> I have colleagues that use pandoc to produce docs, because it's simple
> and heck, they've normalized on it.
> 
> I myself prefer to generate documents straight from LaTeX, but it means
> I can't directly work with them.
> 
> That's most often the situation.
> 
> I would also like a pandoc port. There are about 80 haskell dependencies for
> it, none of it is in our ports tree yet.
> 

FWIW I've been using pandoc via cabal for quite a while now.  Sure, it's
a bit messy, and I've often ended up having to rm -rf ~/.cabal and
reinstalling everything from scratch, which takes a while, but hey, "it
works for me"(tm).

-- 
 

Re: to Pandoc or not

[Zé Loff]

On Wed, Jul 15, 2020 at 06:07:45PM +1200, Tom Wong-Cornall wrote:
> On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
> wrote:
> > I never found pandoc useful for anything - so much so that i never
> > even felt a need to evalute its quality for real.  I dimly remember
> > that on rare occasions, i saw man(7) output generated by pandoc,
> > and if i remeber correctly, that was of poor quality - but i'm not
> > sure and it isn't terribly relevant because pandoc is used very
> > rarely in practice in the first place.
> > 
> > What do you want to do with it?
> 
> As a mutt user, I find pandoc useful to generate HTML mail from a normal 
> plaintext email starting point. Markdown (a valid "from" format for 
> pandoc) is after all essentially just plaintext email "markup", so it's 
> fairly transparent.
> 
> Obviously this might be a rather inflammatory statement in itself, as 
> HTML email is its own special hell for many people, but it's hard to get 
> away from having to send the occasional piece when interacting with the 
> wider world that don't spend their lives like me in an rxvt window.
> 
> There's some nice examples (not mine) here: 
> https://nosubstance.me/post/mutt-secret-sauce/
> 

Would multimarkdown (in ports) be a viable alternative for this?

-- 
 

Re: to Pandoc or not

[Marc Espie]

On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
wrote:
> I never found pandoc useful for anything - so much so that i never
> even felt a need to evalute its quality for real.  I dimly remember
> that on rare occasions, i saw man(7) output generated by pandoc,
> and if i remeber correctly, that was of poor quality - but i'm not
> sure and it isn't terribly relevant because pandoc is used very
> rarely in practice in the first place.
> 
> What do you want to do with it?

I have colleagues that use pandoc to produce docs, because it's simple
and heck, they've normalized on it.

I myself prefer to generate documents straight from LaTeX, but it means
I can't directly work with them.

That's most often the situation.

I would also like a pandoc port. There are about 80 haskell dependencies for
it, none of it is in our ports tree yet.

Re: to Pandoc or not

[Tom Wong-Cornall]

On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
wrote:
> I never found pandoc useful for anything - so much so that i never
> even felt a need to evalute its quality for real.  I dimly remember
> that on rare occasions, i saw man(7) output generated by pandoc,
> and if i remeber correctly, that was of poor quality - but i'm not
> sure and it isn't terribly relevant because pandoc is used very
> rarely in practice in the first place.
> 
> What do you want to do with it?

As a mutt user, I find pandoc useful to generate HTML mail from a normal 
plaintext email starting point. Markdown (a valid "from" format for 
pandoc) is after all essentially just plaintext email "markup", so it's 
fairly transparent.

Obviously this might be a rather inflammatory statement in itself, as 
HTML email is its own special hell for many people, but it's hard to get 
away from having to send the occasional piece when interacting with the 
wider world that don't spend their lives like me in an rxvt window.

There's some nice examples (not mine) here: 
https://nosubstance.me/post/mutt-secret-sauce/

Re: to Pandoc or not

[Ingo Schwarze]

Hi,

sven falempin wrote on Tue, Jul 14, 2020 at 01:23:21PM -0400:

> Is anyone working on that for openbsd ?
> 
> https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile

I never found pandoc useful for anything - so much so that i never
even felt a need to evalute its quality for real.  I dimly remember
that on rare occasions, i saw man(7) output generated by pandoc,
and if i remeber correctly, that was of poor quality - but i'm not
sure and it isn't terribly relevant because pandoc is used very
rarely in practice in the first place.

What do you want to do with it?

Yours,
  Ingo

Re: to Pandoc or not

[Stuart Henderson]

On 2020/07/14 13:23, sven falempin wrote:
> Dear readers,
> 
> Is anyone working on that for openbsd ?
> 
> https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile
> 
> I do not know the Cabal build system nor haskell
> <https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile>so
> I have no idea of the difficulty level of bringing that in ports .
> 
> IE: is it possible to have it work with just a few tweeks
> 
> Best,

You maybe able to build it outside of ports by using cabal (see notes at
https://marc.info/?l=openbsd-ports=152175625404877=2)

It would be nice to have a package of this, but it's not a beginner-level thing 
;)

to Pandoc or not

[sven falempin]

Dear readers,

Is anyone working on that for openbsd ?

https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile

I do not know the Cabal build system nor haskell
<https://github.com/freebsd/freebsd-ports/blob/master/textproc/hs-pandoc/Makefile>so
I have no idea of the difficulty level of bringing that in ports .

IE: is it possible to have it work with just a few tweeks

Best,

Re: Just for fun: cabal install pandoc

[Ingo Schwarze]

Matthias Kilian wrote on Sun, Mar 25, 2018 at 12:59:48AM +0100:
> On Sat, Mar 24, 2018 at 06:51:21PM +0100, Ingo Schwarze wrote:

>> You mean, a documentation package so large and cumbersome
>> that it requires 103 dependencies (not counting haskell
>> and cabal themselves), and that after bumping RAM limits,
>> the leading expert on the language system used needed two
>> tries to even build it?

> I do *not* consider myself an expert in this area, not to
> speak of a *leading* expert ;-)

   $ cd /usr/ports
   $ cvs log */hs-*/Makefile > cvs.log
   $ grep -c '\' cvs.log
  2092
   $ grep ^date: cvs.log | cut -d\  -f 6 | sort | uniq -c | sort -nr
  1840 kili;
   214 espie;
   200 dcoppa;
   117 jasper;
31 jim;
 7 ajacoutot
   [...]

Sounds like a humble expert, then.  :-)

Re: Just for fun: cabal install pandoc

[Matthias Kilian]

Hi,

On Sat, Mar 24, 2018 at 06:51:21PM +0100, Ingo Schwarze wrote:
> You mean, a documentation package so large and cumbersome
> that it requires 103 dependencies (not counting haskell
> and cabal themselves), and that after bumping RAM limits,
> the leading expert on the language system used needed two
> tries to even build it?

I do *not* consider myself an expert in this area, not to speak of
a *leading* expert ;-)

Ciao,
Kili

Re: Just for fun: cabal install pandoc

[Ingo Schwarze]

You mean, a documentation package so large and cumbersome
that it requires 103 dependencies (not counting haskell
and cabal themselves), and that after bumping RAM limits,
the leading expert on the language system used needed two
tries to even build it?

That is amazing indeed.

Just for fun: cabal install pandoc

[Matthias Kilian]

Hi,

=66rom time to time, people ask strange questions about pandoc (which
may be a useful tool to have). After I recently got a problem report
about cabal install pandoc not working correctly (of course with
wild guesses, mumbling about 'haskell-platform' libraries, and
without mentioning wether our ghc package or the binaries from
www.haskell.org had been used), I just gave it a try.

First, with ghc, cabal-install, unzip and *all* hs-* packages
installed.  This failed with a type error when it tried to build
http-client.

The second attempt (with *only* ghc, cabal-install and unzip installed
=66rom packages) succeeded -- well after bumping the datasize limit
a little bit for pandoc itself.

Apart from the fact that the artificial cleverness built into cabal's
dependency resolution algortithms seems to fail (or why would it
fail in-between on some dependency just because some hs-* packages
are globally installed on the system?) below is a typescript of a
successful build.

Any volunteers around for this? ;-)

Ciao,
Kili

ps: yeah, you'll have to arrange cabal things to run everything on
a filesystem mounted wxallowed and with TMPDIR pointing to a directory
on such a filesystem.

Script started on Thu Mar 22 22:21:06 2018
[kili@knecht:kili]$ cabal install pandoc=0D=0D
Resolving dependencies...=0D
Downloading SHA-1.6.4.4...=0D
Downloading base-compat-0.9.3...=0D
Downloading base64-bytestring-1.0.0.1...=0D
Downloading basement-0.0.7...=0D
Configuring base64-bytestring-1.0.0.1...=0D
Configuring base-compat-0.9.3...=0D
Configuring basement-0.0.7...=0D
Building base64-bytestring-1.0.0.1...=0D
Building base-compat-0.9.3...=0D
Configuring SHA-1.6.4.4...=0D
Building basement-0.0.7...=0D
Building SHA-1.6.4.4...=0D
Installed base64-bytestring-1.0.0.1=0D
Downloading byteable-0.1.1...=0D
Configuring byteable-0.1.1...=0D
Building byteable-0.1.1...=0D
Installed byteable-0.1.1=0D
Downloading cereal-0.5.5.0...=0D
Configuring cereal-0.5.5.0...=0D
Installed base-compat-0.9.3=0D
Building cereal-0.5.5.0...=0D
Downloading cmdargs-0.10.20...=0D
Configuring cmdargs-0.10.20...=0D
Building cmdargs-0.10.20...=0D
Installed cereal-0.5.5.0=0D
Downloading colour-2.3.4...=0D
Configuring colour-2.3.4...=0D
Installed cmdargs-0.10.20=0D
Downloading data-default-class-0.1.2.0...=0D
Configuring data-default-class-0.1.2.0...=0D
Building colour-2.3.4...=0D
Building data-default-class-0.1.2.0...=0D
Installed data-default-class-0.1.2.0=0D
Downloading digest-0.0.1.2...=0D
Configuring digest-0.0.1.2...=0D
Building digest-0.0.1.2...=0D
Installed digest-0.0.1.2=0D
Downloading dlist-0.8.0.4...=0D
Configuring dlist-0.8.0.4...=0D
Building dlist-0.8.0.4...=0D
Installed dlist-0.8.0.4=0D
Downloading fail-4.9.0.0...=0D
Configuring fail-4.9.0.0...=0D
Building fail-4.9.0.0...=0D
Installed fail-4.9.0.0=0D
Downloading haddock-library-1.5.0.1...=0D
Configuring haddock-library-1.5.0.1...=0D
Installed colour-2.3.4=0D
Downloading hourglass-0.2.11...=0D
Configuring hourglass-0.2.11...=0D
Building haddock-library-1.5.0.1...=0D
Building hourglass-0.2.11...=0D
Installed hourglass-0.2.11=0D
Downloading hxt-charproperties-9.2.0.1...=0D
Configuring hxt-charproperties-9.2.0.1...=0D
Building hxt-charproperties-9.2.0.1...=0D
Installed SHA-1.6.4.4=0D
Downloading integer-logarithms-1.0.2.1...=0D
Configuring integer-logarithms-1.0.2.1...=0D
Building integer-logarithms-1.0.2.1...=0D
Installed basement-0.0.7=0D
Downloading mtl-2.2.2...=0D
Configuring mtl-2.2.2...=0D
Installed integer-logarithms-1.0.2.1=0D
Downloading network-2.6.3.4...=0D
Building mtl-2.2.2...=0D
Configuring network-2.6.3.4...=0D
Installed mtl-2.2.2=0D
Downloading old-locale-1.0.0.7...=0D
Configuring old-locale-1.0.0.7...=0D
Building old-locale-1.0.0.7...=0D
Installed old-locale-1.0.0.7=0D
Downloading primitive-0.6.3.0...=0D
Configuring primitive-0.6.3.0...=0D
Building primitive-0.6.3.0...=0D
Installed hxt-charproperties-9.2.0.1=0D
Downloading random-1.1...=0D
Configuring random-1.1...=0D
Building random-1.1...=0D
Building network-2.6.3.4...=0D
Installed random-1.1=0D
Downloading safe-0.3.17...=0D
Configuring safe-0.3.17...=0D
Installed primitive-0.6.3.0=0D
Downloading semigroups-0.18.4...=0D
Configuring semigroups-0.18.4...=0D
Building safe-0.3.17...=0D
Building semigroups-0.18.4...=0D
Installed haddock-library-1.5.0.1=0D
Downloading split-0.2.3.3...=0D
Configuring split-0.2.3.3...=0D
Installed semigroups-0.18.4=0D
Downloading stm-2.4.5.0...=0D
Configuring stm-2.4.5.0...=0D
Building split-0.2.3.3...=0D
Building stm-2.4.5.0...=0D
Installed safe-0.3.17=0D
Downloading syb-0.7...=0D
Configuring syb-0.7...=0D
Installed split-0.2.3.3=0D
Downloading text-1.2.3.0...=0D
Building syb-0.7...=0D
Configuring text-1.2.3.0...=0D
Installed network-2.6.3.4=0D
Downloading th-abstraction-0.2.6.0...=0D
Configuring th-abstraction-0.2.6.0...=0D
Building text-1.2.3.0...=0D
Installed stm-2.4.5.0=0D
Downloading time-locale-compat-0.1.1.3...=0D
Configuring time-locale-compat-0.1.1.3...=0D
Building th-abstraction-0.2.6.0...=0D

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

Hi Kili,

On 06/17/16 01:32, Matthias Kilian wrote:
> Hi,
> 
> On Thu, Jun 16, 2016 at 05:34:09PM -0500, Aaron Poffenberger wrote:
>> Thanks to your suggestion and a pointer to the Java "maven" thread by
>> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
>> the cabal dependencies using DISTFILES.
>>
>> I tested building pandoc with networking disabled. It works.
> 
> I don't think this cabal sandbox model is suitable for ports in any
> way.  What will happen if we enable shared libraries for ghc (which,
> according to some mails from Karel Gardas, should be possible with
> ghc-8)? Where will those libraries be end up in ${LOCALBASE}?

For the most part, the value of sandboxing the build will be to build
stand-alone executables like pandoc. Once built, the bits from
MODGHC_CABAL_SANDBOX aren't further referenced and may be safely deleted.

> 
> And do you think it's useful to have several different versions of
> the same haskell library sprinkled over the system?
> 
> In the pandoc port, MODGHC_CABAL_PKGS even contains library/version
> combinations we already have as separate ports.

The point of specifying the versions is those are the exact combination
of pkgs the cabal resolver determined will work together based on the
constraints from the pandoc.cabal file *and* the libraries I required in
RUN_DEPENDS-lib.

The versions are also required since BULK(8) builds don't allow network
access. As I understand it, everything has to be downloaded into
FULLDISTDIR before configure begins.

> 
> Sorry, but I'm not a big fan of this concept.
> 
> BTW, the pandoc-lib subpackage doesn't make any sense unless it
> does not depend on any of the cabal packages listed in MODGHC_CABAL_PKGS,
> because the libraries provided by those packages would be missing
> (they aren't installed). It also wouldn't install properly because
> PLIST-lib is wrong.

You're right about the -lib pkg. It won't work as currently ported. The
chief aim of sandboxing was to make standalone binaries possible without
a recursive porting effort for all the dependencies.

There are three possible resolutions: 1) don't include the -lib in the
package, 2) install the dependencies in
${LOCALBASE}/lib/ghc/pandoc-1.17.1 and update register.sh, or 3) scrap
the sandboxing idea altogether.

I don't like the last idea: scrapping sandboxing. pandoc has huge, unmet
dependency lists. And even if one were to recursively port every missing
dependency we still might have conflicts with existing ports due to
version-requirement conflicts. This would lead to having the same pkg
ported twice but for different versions.

I'm sure you know this is why Haskell-LTS was started: to create a
stable list of pkgs that work together. Unless we're following a
specific LTS release, we will run into version conflicts at some point.

(I think following a specific LTS release would be a good idea, but
that's a conversation for another email.)

Sandboxing solves this problem, certainly for binaries. And could
resolve library conflicts if libs can have their unmet dependencies
installed in their ${LOCALBASE}/lib/pkg dir.

Cheers,

--Aaron

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Matthias Kilian]

Hi,

On Thu, Jun 16, 2016 at 05:34:09PM -0500, Aaron Poffenberger wrote:
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
> 
> I tested building pandoc with networking disabled. It works.

I don't think this cabal sandbox model is suitable for ports in any
way.  What will happen if we enable shared libraries for ghc (which,
according to some mails from Karel Gardas, should be possible with
ghc-8)? Where will those libraries be end up in ${LOCALBASE}?

And do you think it's useful to have several different versions of
the same haskell library sprinkled over the system?

In the pandoc port, MODGHC_CABAL_PKGS even contains library/version
combinations we already have as separate ports.

Sorry, but I'm not a big fan of this concept.

BTW, the pandoc-lib subpackage doesn't make any sense unless it
does not depend on any of the cabal packages listed in MODGHC_CABAL_PKGS,
because the libraries provided by those packages would be missing
(they aren't installed). It also wouldn't install properly because
PLIST-lib is wrong.

Ciao,
Kili

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

On 06/16/16 17:34, Aaron Poffenberger wrote:
> On 06/15/16 07:46, Stuart Henderson wrote:
>> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>>> You are right. cabal can install from a local path. Is it possible to
>>> feed a bunch of files into the process by adding them to distinfo?
>>
>> Aha: if you can list the distfiles in DISTFILES and point cabal at them
>> locally that should work.
>>
>> Fetching will be a little messy if the files are in separate subdirs
>> as I think they are on hackage, but it can be handled by using the
>> filename{url}sufx syntax in DISTFILES for them, e.g.
>> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
>> devel/cargo is doing (peril-sensitive glasses advised before looking
>> at the regexp there ;)
>>
>> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
>> them itself, and ${FULLDISTDIR} to get the path.
>>
> Hi Stuart,
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
> 
> I tested building pandoc with networking disabled. It works.
> 
> I forgot that cabal expects package repos to have a specific structure
> and manifest describing the repo. I've implemented the necessary code to
> build it. Any comments on improving that section would be welcome.
> 
> I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
> cabal repo (MODGHC_CABAL_REPO).
> 
> The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
> default.
> 
> Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
> sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
> since it's just symlinks and a manifest there's not much value.
> 
> N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
> in ghc.port.mk for instructions on proper initialization.
> 
> Attached are the revised patch and example port of pandoc for testing with.
> 
> --Aaron
> 

Attached are the same files as before plus a patch for port-modules.5.

I documented the *sandbox* build action and added a "Defines" section to
document use of three variables that porters will need to know about to
sandbox.

I also moved the explanation of the two variables MODGHC_SETUP_CONF_ARGS
and MODGHC_SETUP_CONF_ENV from what was the final paragraph into the
"Defines" section for consistency.

--Aaron



pandoc-1.17.1.tgz
Description: Binary data
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk	20 Jan 2016 16:08:29 -	1.38
+++ ghc.port.mk	16 Jun 2016 22:22:35 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
 # $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
 # Module for Glasgow Haskell Compiler
 
@@ -55,7 +56,21 @@ DIST_SUBDIR ?=			ghc
 
 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?=		Setup.lhs Setup.hs
+.  if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS +=			devel/cabal-install
+# Set MODGHC_CABAL_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_CABAL_SANDBOX}
+# cd ${MODGHC_CABAL_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_CABAL_PKGS ?=
+MODGHC_CABAL_REPO ?=		${WRKSRC}/.local-repo
+MODGHC_CABAL_SANDBOX ?=		${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?=		${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?=		${WRKSRC}/Setup
+.  else
 MODGHC_SETUP_PROG ?=		${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?=		${MODGHC_SETUP_PROG}
+.  endif
 MODGHC_SETUP_CONF_ARGS ?=
 MODGHC_SETUP_CONF_ENV ?=
 
@@ -76,6 +91,56 @@ MODGHC_SETUP_CONF_ARGS +=	--docdir=\$$da
 # Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
 # without a do-configure: target (some Haskell ports are built with
 # Cabal but use autohell for the documentation):
+.  if ${MODGHC_BUILD:L:Msandbox}
+# Build a cabal repo from downloaded packages
+.   for _pkg in ${MODGHC_CABAL_PKGS}
+_ver :=		${_pkg:C,.*-([0-9.]*)$,\1,}
+_name :=	${_pkg:C,-[0-9.]*$,,}
+_path :=	${_ver}/${_name}
+_tgz :=		${_pkg}.tar.gz
+MODGHC_CABAL_PATHS +:=		${_path}
+MODGHC_CABAL_LINK_CMDS +:=	"ln -sf ${FULLDISTDIR}/${_pkg}/${_tgz} ${_path}"
+MODGHC_CABAL_EXTRACT_CMDS +:="tar xzf ${_path}/${_tgz} ${_pkg}/${_name}.cabal"
+MODGHC_CABAL_MOVE_CMDS +:=	"mv ${_pkg}/${_name}.cabal ${_path}"
+MODGHC_CABAL_RMDIR_CMDS +:=	"rmdir ${_pkg}"
+.   endfor
+
+MODCABAL_configure = \
+	mkdir -p ${MODGHC_CABAL_REPO}/packages && \
+	cd ${MODGHC_CABAL_REPO}/packages && \
+	for s in ${MODGHC_CABAL_PATHS}; do \
+		mkdir -p "$$s"; \

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

On 06/16/16 17:34, Aaron Poffenberger wrote:
> On 06/15/16 07:46, Stuart Henderson wrote:
>> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>>> You are right. cabal can install from a local path. Is it possible to
>>> feed a bunch of files into the process by adding them to distinfo?
>>
>> Aha: if you can list the distfiles in DISTFILES and point cabal at them
>> locally that should work.
>>
>> Fetching will be a little messy if the files are in separate subdirs
>> as I think they are on hackage, but it can be handled by using the
>> filename{url}sufx syntax in DISTFILES for them, e.g.
>> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
>> devel/cargo is doing (peril-sensitive glasses advised before looking
>> at the regexp there ;)
>>
>> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
>> them itself, and ${FULLDISTDIR} to get the path.
>>
> Hi Stuart,
> Thanks to your suggestion and a pointer to the Java "maven" thread by
> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
> the cabal dependencies using DISTFILES.
> 
> I tested building pandoc with networking disabled. It works.
> 
> I forgot that cabal expects package repos to have a specific structure
> and manifest describing the repo. I've implemented the necessary code to
> build it. Any comments on improving that section would be welcome.
> 
> I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
> cabal repo (MODGHC_CABAL_REPO).
> 
> The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
> default.
> 
> Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
> sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
> since it's just symlinks and a manifest there's not much value.
> 
> N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
> in ghc.port.mk for instructions on proper initialization.
> 
> Attached are the revised patch and example port of pandoc for testing with.
> 
> --Aaron
> 
Realized on the way home I'll need to modify port-modules(5) for this to
be a complete solution. I'll start on that next.

--Aaron

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

On 06/15/16 07:46, Stuart Henderson wrote:
> On 2016/06/15 07:12, Aaron Poffenberger wrote:
>> You are right. cabal can install from a local path. Is it possible to
>> feed a bunch of files into the process by adding them to distinfo?
> 
> Aha: if you can list the distfiles in DISTFILES and point cabal at them
> locally that should work.
> 
> Fetching will be a little messy if the files are in separate subdirs
> as I think they are on hackage, but it can be handled by using the
> filename{url}sufx syntax in DISTFILES for them, e.g.
> {path/to/}filename-$V.tar.gz which would be somewhat similar to what
> devel/cargo is doing (peril-sensitive glasses advised before looking
> at the regexp there ;)
> 
> You can use EXTRACT_ONLY to stop ports infra from trying to unpack
> them itself, and ${FULLDISTDIR} to get the path.
> 
Hi Stuart,
Thanks to your suggestion and a pointer to the Java "maven" thread by
Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
the cabal dependencies using DISTFILES.

I tested building pandoc with networking disabled. It works.

I forgot that cabal expects package repos to have a specific structure
and manifest describing the repo. I've implemented the necessary code to
build it. Any comments on improving that section would be welcome.

I'm using symlinks between the tarballs in ${FULLDISTDIR} and the local
cabal repo (MODGHC_CABAL_REPO).

The cabal sandbox is also a local directory (MODGHC_CABAL_SANDBOX) by
default.

Of the two, MODGHC_CABAL_SANDBOX is a good candidate for sharing between
sandboxed builds. You could create a shared repo (MODGHC_CABAL_REPO) but
since it's just symlinks and a manifest there's not much value.

N.B. to anyone who uses a shared MODGHC_CABAL_SANDBOX, read the comment
in ghc.port.mk for instructions on proper initialization.

Attached are the revised patch and example port of pandoc for testing with.

--Aaron



pandoc-1.17.1.tgz
Description: Binary data
Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk	20 Jan 2016 16:08:29 -	1.38
+++ ghc.port.mk	16 Jun 2016 22:22:35 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
 # $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
 # Module for Glasgow Haskell Compiler
 
@@ -55,7 +56,21 @@ DIST_SUBDIR ?=			ghc
 
 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?=		Setup.lhs Setup.hs
+.  if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS +=			devel/cabal-install
+# Set MODGHC_CABAL_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_CABAL_SANDBOX}
+# cd ${MODGHC_CABAL_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_CABAL_PKGS ?=
+MODGHC_CABAL_REPO ?=		${WRKSRC}/.local-repo
+MODGHC_CABAL_SANDBOX ?=		${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?=		${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?=		${WRKSRC}/Setup
+.  else
 MODGHC_SETUP_PROG ?=		${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?=		${MODGHC_SETUP_PROG}
+.  endif
 MODGHC_SETUP_CONF_ARGS ?=
 MODGHC_SETUP_CONF_ENV ?=
 
@@ -76,6 +91,56 @@ MODGHC_SETUP_CONF_ARGS +=	--docdir=\$$da
 # Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
 # without a do-configure: target (some Haskell ports are built with
 # Cabal but use autohell for the documentation):
+.  if ${MODGHC_BUILD:L:Msandbox}
+# Build a cabal repo from downloaded packages
+.   for _pkg in ${MODGHC_CABAL_PKGS}
+_ver :=		${_pkg:C,.*-([0-9.]*)$,\1,}
+_name :=	${_pkg:C,-[0-9.]*$,,}
+_path :=	${_ver}/${_name}
+_tgz :=		${_pkg}.tar.gz
+MODGHC_CABAL_PATHS +:=		${_path}
+MODGHC_CABAL_LINK_CMDS +:=	"ln -sf ${FULLDISTDIR}/${_pkg}/${_tgz} ${_path}"
+MODGHC_CABAL_EXTRACT_CMDS +:="tar xzf ${_path}/${_tgz} ${_pkg}/${_name}.cabal"
+MODGHC_CABAL_MOVE_CMDS +:=	"mv ${_pkg}/${_name}.cabal ${_path}"
+MODGHC_CABAL_RMDIR_CMDS +:=	"rmdir ${_pkg}"
+.   endfor
+
+MODCABAL_configure = \
+	mkdir -p ${MODGHC_CABAL_REPO}/packages && \
+	cd ${MODGHC_CABAL_REPO}/packages && \
+	for s in ${MODGHC_CABAL_PATHS}; do \
+		mkdir -p "$$s"; \
+	done && \
+	for s in ${MODGHC_CABAL_LINK_CMDS}; do \
+		$$s; \
+	done && \
+	for s in ${MODGHC_CABAL_EXTRACT_CMDS}; do \
+		$$s; \
+	done && \
+	for s in ${MODGHC_CABAL_MOVE_CMDS}; do \
+		$$s; \
+	done && \
+	for s in ${MODGHC_CABAL_RMDIR_CMDS}; do \
+		$$s; \
+	done && \
+	find . -type f -name '*.cabal' >> files && \
+	tar -cf 00-index.tar -I files && \
+	rm -f files && \
+	cd ${WRKSRC} && \
+	${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_CABAL_SANDBOX} && \
+	echo "local-repo: ${MODGHC_CABAL_REPO}/packages" > cabal.config && \
+	${MODGHC_SETUP_PROG} install --onl

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Marc Espie]

For those interested, I added a man page called bulk(8) to
ports/infrastructure recently.

It does explain in some details how to setup a cluster for package
building.

This is *de facto* the standard you have to deal with   for all ports.
Official and development build clusters are built using those recommendations,
and in particular, we don't intend to go back to "one user fits all" builds
(if anything there will be even MORE separation in the future).

There are several people already using _pbuild and _pfetch with _pbuild 
prevented from any interaction with the network, in close kept chroots.

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Stuart Henderson]

On 2016/06/15 07:12, Aaron Poffenberger wrote:
> You are right. cabal can install from a local path. Is it possible to
> feed a bunch of files into the process by adding them to distinfo?

Aha: if you can list the distfiles in DISTFILES and point cabal at them
locally that should work.

Fetching will be a little messy if the files are in separate subdirs
as I think they are on hackage, but it can be handled by using the
filename{url}sufx syntax in DISTFILES for them, e.g.
{path/to/}filename-$V.tar.gz which would be somewhat similar to what
devel/cargo is doing (peril-sensitive glasses advised before looking
at the regexp there ;)

You can use EXTRACT_ONLY to stop ports infra from trying to unpack
them itself, and ${FULLDISTDIR} to get the path.

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

Hi Stuart,

On 06/15/16 06:56, Stuart Henderson wrote:
> Hi Aaron,
> 
> On 2016/06/14 21:08, Aaron Poffenberger wrote:
>> Below is a patch to add cabal-sandbox support to ghc.port.mk, to build
>> Haskell package-dependencies in a sandbox.
> 
> The patch got word-wrapped (you can send attachments to ports@
> if that's easiest).

Attached.

> 
>> The motivation is to make porting packages with large, unmet
>> dependency-lists easier.
> 
> This suggests that it's downloading during build. If I'm right then
> sorry for the bad news but unfortunately it won't work out that way,
> the only network access we permit during bulk builds is controlled
> by DPB during the fetch stage so it must be done as standard distfiles
> fetched by http/ftp and with checksums in the distinfo file. 
> 
>> If there's no interest or significant concerns with sandboxing, I'll
>> work on a regular port of pandoc by first porting it's dependencies.
> 
> I wonder if this might be something that would be reasonable to
> handle via portgen..
> 

You are right. cabal can install from a local path. Is it possible to
feed a bunch of files into the process by adding them to distinfo?

Alternatively, I had been thinking to make a portgen for Haskell. I'll
look at the code to see what's required.


Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk	20 Jan 2016 16:08:29 -	1.38
+++ ghc.port.mk	15 Jun 2016 01:36:51 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
 # $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
 # Module for Glasgow Haskell Compiler
 
@@ -55,7 +56,19 @@ DIST_SUBDIR ?=			ghc
 
 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?=		Setup.lhs Setup.hs
+.  if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS +=			devel/cabal-install
+# Set MODGHC_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_SANDBOX}
+# cd ${MODGHC_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_SANDBOX ?=			${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?=		${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?=		${WRKSRC}/Setup
+.  else
 MODGHC_SETUP_PROG ?=		${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?=		${MODGHC_SETUP_PROG}
+.  endif
 MODGHC_SETUP_CONF_ARGS ?=
 MODGHC_SETUP_CONF_ENV ?=
 
@@ -76,6 +89,23 @@ MODGHC_SETUP_CONF_ARGS +=	--docdir=\$$da
 # Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
 # without a do-configure: target (some Haskell ports are built with
 # Cabal but use autohell for the documentation):
+.  if ${MODGHC_BUILD:L:Msandbox}
+MODCABAL_configure = \
+	cd ${WRKSRC} && \
+	${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_SANDBOX} && \
+	${MODGHC_SETUP_PROG} update && \
+	${MODGHC_SETUP_PROG} install --only-dependencies ${MODGHC_SETUP_CONF_ARGS} && \
+	for s in ${MODGHC_SETUP_SCRIPT}; do \
+		test -f "$$s" && \
+		${MODGHC_BIN} --make \
+			-o ${MODGHC_REGISTER_PROG} "$$s" && \
+		break; \
+	done && \
+	cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} ${MODGHC_SETUP_CONF_ENV} \
+		${MODGHC_SETUP_PROG} \
+			configure -v -g -O --prefix=${PREFIX} \
+			${MODGHC_SETUP_CONF_ARGS}
+.  else
 MODCABAL_configure = \
 	cd ${WRKSRC} && \
 	for s in ${MODGHC_SETUP_SCRIPT}; do \
@@ -88,6 +118,7 @@ MODCABAL_configure = \
 		${MODGHC_SETUP_PROG} \
 			configure -v -g -O --prefix=${PREFIX} \
 			${MODGHC_SETUP_CONF_ARGS}
+.  endif
 
 CONFIGURE_STYLE +=		CABAL
 
@@ -102,9 +133,9 @@ MODGHC_BUILD_TARGET += \
 .  if ${MODGHC_BUILD:L:Mregister}
 MODGHC_BUILD_TARGET += \
 	;cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
-		${MODGHC_SETUP_PROG} register --gen-script; \
+		${MODGHC_REGISTER_PROG} register --gen-script; \
 	cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
-		${MODGHC_SETUP_PROG} unregister --gen-script
+		${MODGHC_REGISTER_PROG} unregister --gen-script
 .  endif
 
 MODGHC_INSTALL_TARGET = \

Re: Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Stuart Henderson]

Hi Aaron,

On 2016/06/14 21:08, Aaron Poffenberger wrote:
> Below is a patch to add cabal-sandbox support to ghc.port.mk, to build
> Haskell package-dependencies in a sandbox.

The patch got word-wrapped (you can send attachments to ports@
if that's easiest).

> The motivation is to make porting packages with large, unmet
> dependency-lists easier.

This suggests that it's downloading during build. If I'm right then
sorry for the bad news but unfortunately it won't work out that way,
the only network access we permit during bulk builds is controlled
by DPB during the fetch stage so it must be done as standard distfiles
fetched by http/ftp and with checksums in the distinfo file. 

> If there's no interest or significant concerns with sandboxing, I'll
> work on a regular port of pandoc by first porting it's dependencies.

I wonder if this might be something that would be reasonable to
handle via portgen..

Sandboxing Haskell Port Builds: ghc.port.mk diff + example converters/pandoc

[Aaron Poffenberger]

Hello ports@,
Below is a patch to add cabal-sandbox support to ghc.port.mk, to build
Haskell package-dependencies in a sandbox.

The patch adds two new variables, a MODGHC_BUILD option "sandbox" and
modifies MODCABAL_configure and MODGHC_BUILD_TARGET.

Most of the diff should be obvious. I had to add MODGHC_SETUP_PROG and
update MODGHC_BUILD_TARGET to use it when registering and unregistering
because cabal doesn't have the unregister command.

The motivation is to make porting packages with large, unmet
dependency-lists easier. converters/pandoc is an example of such a
package. I've included the port as an example of building a port using
dependencies from ports where available and sandboxing for the rest.

Sandboxing dependency builds is also helpful in cases of version conflicts.

If there's no interest or significant concerns with sandboxing, I'll
work on a regular port of pandoc by first porting it's dependencies.

--Aaron

Index: ghc.port.mk
===
RCS file: /home/cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.38
diff -u -p -u -r1.38 ghc.port.mk
--- ghc.port.mk 20 Jan 2016 16:08:29 -  1.38
+++ ghc.port.mk 15 Jun 2016 01:36:51 -
@@ -1,3 +1,4 @@
+#-*- mode: Makefile; tab-width: 4; -*-
 # $OpenBSD: ghc.port.mk,v 1.38 2016/01/20 16:08:29 kili Exp $
 # Module for Glasgow Haskell Compiler

@@ -55,7 +56,19 @@ DIST_SUBDIR ?=   ghc

 . if ${MODGHC_BUILD:L:Mcabal}
 MODGHC_SETUP_SCRIPT ?= Setup.lhs Setup.hs
+.  if ${MODGHC_BUILD:L:Msandbox}
+BUILD_DEPENDS +=   devel/cabal-install
+# Set MODGHC_SANDBOX to system-wide value to reuse packages
+# across builds. Be sure to initialize it first.
+# mkdir -p ${MODGHC_SANDBOX}
+# cd ${MODGHC_SANDBOX} && cabal sandbox init --sandbox .
+MODGHC_SANDBOX ?=  ${WRKSRC}/.cabal-sandbox
+MODGHC_SETUP_PROG ?=   ${LOCALBASE}/bin/cabal
+MODGHC_REGISTER_PROG ?=${WRKSRC}/Setup
+.  else
 MODGHC_SETUP_PROG ?=   ${WRKSRC}/Setup
+MODGHC_REGISTER_PROG ?=${MODGHC_SETUP_PROG}
+.  endif
 MODGHC_SETUP_CONF_ARGS ?=
 MODGHC_SETUP_CONF_ENV ?=

@@ -76,6 +89,23 @@ MODGHC_SETUP_CONF_ARGS +=--docdir=\$$da
 # Little hack to let ports still add CONFIGURE_STYLE = autoconf and go
 # without a do-configure: target (some Haskell ports are built with
 # Cabal but use autohell for the documentation):
+.  if ${MODGHC_BUILD:L:Msandbox}
+MODCABAL_configure = \
+   cd ${WRKSRC} && \
+   ${MODGHC_SETUP_PROG} sandbox init --sandbox=${MODGHC_SANDBOX} && \
+   ${MODGHC_SETUP_PROG} update && \
+   ${MODGHC_SETUP_PROG} install --only-dependencies
${MODGHC_SETUP_CONF_ARGS} && \
+   for s in ${MODGHC_SETUP_SCRIPT}; do \
+   test -f "$$s" && \
+   ${MODGHC_BIN} --make \
+   -o ${MODGHC_REGISTER_PROG} "$$s" && \
+   break; \
+   done && \
+   cd ${WRKBUILD} && exec ${SETENV} ${MAKE_ENV} ${MODGHC_SETUP_CONF_ENV} \
+   ${MODGHC_SETUP_PROG} \
+   configure -v -g -O --prefix=${PREFIX} \
+   ${MODGHC_SETUP_CONF_ARGS}
+.  else
 MODCABAL_configure = \
cd ${WRKSRC} && \
for s in ${MODGHC_SETUP_SCRIPT}; do \
@@ -88,6 +118,7 @@ MODCABAL_configure = \
${MODGHC_SETUP_PROG} \
configure -v -g -O --prefix=${PREFIX} \
${MODGHC_SETUP_CONF_ARGS}
+.  endif

 CONFIGURE_STYLE += CABAL

@@ -102,9 +133,9 @@ MODGHC_BUILD_TARGET += \
 .  if ${MODGHC_BUILD:L:Mregister}
 MODGHC_BUILD_TARGET += \
;cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
-   ${MODGHC_SETUP_PROG} register --gen-script; \
+   ${MODGHC_REGISTER_PROG} register --gen-script; \
cd ${WRKBUILD} && ${SETENV} ${MAKE_ENV} \
-   ${MODGHC_SETUP_PROG} unregister --gen-script
+   ${MODGHC_REGISTER_PROG} unregister --gen-script
 .  endif

 MODGHC_INSTALL_TARGET = \


pandoc-1.17.1.tgz
Description: Binary data

Anyone working on pandoc?

[Zé Loff]

Hi all

Has anyone tried / started to port pandoc, or knows of any good reason
not to? I'd like to give it a shot, but I don't want do duplicate
efforts...

Cheers
Zé

-- 

Re: Anyone working on pandoc?

[Zé Loff]

On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote:
 On 2014-06-19, 9:42 AM, Zé Loff wrote:
 Hi all
 
 Has anyone tried / started to port pandoc, or knows of any good reason
 not to? I'd like to give it a shot, but I don't want do duplicate
 efforts...
 
 
 Yes, I have it mostly done (a dozen or so new dependencies, of course), but
 it's on hold waiting for the annual churnover of Haskell GHC port.

Nice, thanks. Let me know if I can help.

Cheers
Zé

-- 

Re: Anyone working on pandoc?

[Ian Darwin]

On 2014-06-19, 9:42 AM, Zé Loff wrote:

Hi all

Has anyone tried / started to port pandoc, or knows of any good reason
not to? I'd like to give it a shot, but I don't want do duplicate
efforts...


Yes, I have it mostly done (a dozen or so new dependencies, of course), 
but it's on hold waiting for the annual churnover of Haskell GHC port.

Re: Anyone working on pandoc?

[Enric Morales]

On 19 Jun 2014 15:23, Zé Loff wrote:
 On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote:
  On 2014-06-19, 9:42 AM, Zé Loff wrote:
  Hi all
  
  Has anyone tried / started to port pandoc, or knows of any good reason
  not to? I'd like to give it a shot, but I don't want do duplicate
  efforts...
  
  
  Yes, I have it mostly done (a dozen or so new dependencies, of course), but
  it's on hold waiting for the annual churnover of Haskell GHC port.
 
 Nice, thanks. Let me know if I can help.
 
 Cheers
 Zé
 
 -- 
 

Hi Zé and Ian,

I am also a pandoc user so I'll try the port when it's available.
Meanwhile, the cabal version works fine. The only problem is that,
every time pandoc has to be rebuilt, it might take at least one hour.

Cheers!

Re: Anyone working on pandoc?

[Matthias Kilian]

Hi,

On Thu, Jun 19, 2014 at 03:23:27PM +0100, Zé Loff wrote:
 On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote:
  On 2014-06-19, 9:42 AM, Zé Loff wrote:
  Has anyone tried / started to port pandoc, or knows of any good reason
  not to? I'd like to give it a shot, but I don't want do duplicate
  efforts...
  
  
  Yes, I have it mostly done (a dozen or so new dependencies, of course), but
  it's on hold waiting for the annual churnover of Haskell GHC port.
 
 Nice, thanks. Let me know if I can help.

Short story: try older versions of pandoc which can be built with
aeson-0.6, *not* requiring any library which meta/haskell-platform
depends on to be changed. pandoc-1.12.3.3 may be worth a try.

Long story:

The biggest problem is that the latest version of pandoc needs
aeson-0.7, which needs attoparsec-=0.11.3.4, but the haskell-platform
dictates attoparsec-0.10.4.0 (and even the current drafts of
haskell-platform-2014 still depends on that same version of
attoparsec).

That means that even after the yearly churn of haskell ports (which
I'll hopefully start in two or three weeks), our port of attoparsec
has to stay at 0.10.4.0. For pandoc (or aeson-0.7), we would need
a separate port/package hs-attoparsec-0.11 (or maybe -0.12?).

But with two different ports of hs-attoparsec, for every existing port
depending on hs-attoparsec (0.10), you'll have to make sure that either

- it doesn't pick up hs-attoparsec-0.11 by accident when it's
  installed (by looking at its cabal file, and maybe patching it to
  depend on attoparsec-0.11), or

- it builds and works with attoparsec-0.11, depends on it (in the port's
  Makefile) and *never* picks up an installed hs-attoparsec (0.10)
  because of other dependency constraints.

I'd prefer to not doing such a stunt, because it's unmaintainable.

Better go back a few releases of pandoc (see above) and then try
to find out whether the newer releases really need aeson-0.7 (and
probably other stuff causing similar problems) and wether they could
be patched to still work with aeson-0.6. (Or try to get aeson-0.7
working with attoparsec-0.10)

Ciao,
Kili

Haskell-Platform-2014 (was: Anyone working on pandoc?)

[Matthias Kilian]

On Thu, Jun 19, 2014 at 07:46:28PM +0200, Matthias Kilian wrote:
 The biggest problem is that the latest version of pandoc needs
 aeson-0.7, which needs attoparsec-=0.11.3.4, but the haskell-platform
 dictates attoparsec-0.10.4.0 (and even the current drafts of
 haskell-platform-2014 still depends on that same version of
 attoparsec).

BTW: a list of haskell-platform-2014 will probably contain can be
nowdays found here:

https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Releases2014.hs

(unless upstream changes their mind and suddenlly puts this information
somwhere else, which *did* happen in the past)

Ciao,
Kili

text/hs-pandoc (was: Enable cabal test-suites for hs-ports by default?)

[Matthias Kilian]

On Tue, Dec 04, 2012 at 02:38:02PM -0500, Predrag Punosevac wrote:
 This is an OT. Any chance that one of you Haskell guys gets pandoc
 ported to OpenBSD.
 
 http://johnmacfarlane.net/pandoc/

Looking at http://hackage.haskell.org/package/pandoc, there are a
couple of dependencies currently not in our ports tree (at least
citeproc-hs, highlighting-kate, json, pandoc-types, temporary,
texmath, and everything those depend on).

This may be an easy job, or it may open a whole can of worms.

 P.S. I tried installing with cabal but it just returns a slue of
 complains. 

Can you send me some logs? Using cabal (the program, from package
cabal-install) should work. If it doesn't, there's some bug either
in pandoc or some of its dependencies, or in our ghc / hs-* ports.

Ciao,
Kili

haskell-pandoc

[Predrag Punosevac]

Alexander Polakov p...@sdf.org wrote:

 * Predrag Punosevac punoseva...@gmail.com [121205 00:40]:
  On Mon, Dec 03, 2012 at 10:32:56PM +0100, Matthias Kilian wrote:
   I'd like to add --enable-tests by default in ghc.port.mk, unless a
   hs-ports has set NO_REGRESS=Yes.
  [...]
  
  This is an OT. Any chance that one of you Haskell guys gets pandoc
  ported to OpenBSD.
  
  http://johnmacfarlane.net/pandoc/
  
  P.S. I tried installing with cabal but it just returns a slue of
  complains. 
  

 pandoc installs and works fine here on -current/i386.

I can confirm this! I just compiled cabal-install from ports on the i386
current.

$ uname -a
OpenBSD foo.my.domain 5.2 GENERIC.MP#107 i386

Inspite 

$ cabal update
Downloading the latest package list from hackage.haskell.org
Note: there is a new version of cabal-install available.
To upgrade, run: cabal install cabal-install


I didn't want to install new cabal-install I just went with the one from
ports. This is the result

Registering pandoc-1.9.4.5...
Preprocessing executable 'make-pandoc-man-pages' for pandoc-1.9.4.5...
[1 of 1] Compiling Main ( man/make-pandoc-man-pages.hs,
dist/build/make-pandoc-man-pages/make-pandoc-man-pages-tmp/Main.o )
Linking dist/build/make-pandoc-man-pages/make-pandoc-man-pages ...
/usr/local/lib/ghc/libHSrts.a(RtsFlags.o)(.text+0x2a2): In function
`copyArg':
: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/ghc/libHSrts.a(RtsUtils.o)(.text+0x2f2): In function
`showStgWord64':
: warning: sprintf() is often misused, please use snprintf()
Installing library in /home/predrag/.cabal/lib/pandoc-1.9.4.5/ghc-7.4.2
Installing executable(s) in /home/predrag/.cabal/bin
Registering pandoc-1.9.4.5...
$ 

So it comes out successfully. 


Best,
Predrag




 -- 
 Alexander Polakov | plhk.ru