Bug#1069179: pandoc: use "--enable-executable-dynamic" in d/rules to reduce binary size on loong64
Hi Dandan Zhang. Quoting zhangdandan (2024-04-17 14:13:00) > The pandoc is blocked from building by haskell-pandoc and > haskell-pandoc-lua-engine in the Debian Package Auto-Building environment. > I have built haskell-pandoc and haskell-pandoc-lua-engine locally, and > then compiling pandoc for loong64 in my local ENV failed. > > The error message is related to "relocation R_LARCH_B26 overflow .." > during static linking when built pandoc binary. > The build error log of pandoc from my local ENV is as follows, > ``` > [4 of 4] Linking dist-ghc/build/pandoc/pandoc > /usr/bin/ld.bfd: > /usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o): > > relocation R_LARCH_B26 overflow 0xf62f45e4 > Dump relocate record: > stack top relocation name symbol > at > /usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x0): > ... > 0x R_LARCH_NONE `' + 3(0x3) > .. > ``` > > It is recommended to use "--enable-executable-dynamic" in d/rules to > reduce binary size on loong64. > The parameter "--enable-executable-dynamic" means "enable dynamic > linking of executable files". > Please consider the patch I attached. > With the attached patch, the pandoc was built successfully in my local ENV. > ``` > .. > if grep -q '^Component:[[:space:]]*main' /CurrentlyBuilding 2>/dev/null; > then dh_scour -ppandoc ; fi > dh_md5sums -ppandoc > dh_builddeb -ppandoc > dpkg-deb: building package 'pandoc' in '../pandoc_3.1.3+ds-2_loong64.deb'. > dpkg-genbuildinfo -O../pandoc_3.1.3+ds-2_loong64.buildinfo > dpkg-genchanges -O../pandoc_3.1.3+ds-2_loong64.changes > ``` > > Your opinions are welcome. > In addition, before the pandoc was built for loong64 in the Debian > Package Auto-Building environment, could I dupload the pandoc compiled > locally using "-enable-executable-dynamic" to the > debian-ports/pool-loong64 repository? > Looking forward to your reply. Unfortunately, Debian treat Haskell libraries as development code, and the option --enable-executable-dynamic works only when development files are also installed. I have instead added loong64 to the list of low-memory architectures, which means these options are applied: --ghc-options="-optc--param -optcggc-min-expand=10 -O0" Hopefully that is enough for the build for loong64 succeeds. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1062045: Acknowledgement (pandoc: generates documentation with invalid fonts in groff output)
Control: reassign -1 libghc-pandoc-dev Control: force-merge 1053777 -1 Control: affects 1053777 pandoc Hi Loren, Quoting Loren M. Lang (2024-01-31 08:35:12) > I left the detail description out of the original report. Current > version of pandoc will create *roff output during man page generation > that refers to invalid fonts C, CI, and possibly others. This will > trigger lintian warnings such as the following for packages using pandoc > to build their man pages: > > groff-message troff::89: warning: cannot select font 'C' > > This is a known issue and has been fixed upstream in pandoc 3.1.7 as > documented in this issue: > > https://github.com/jgm/pandoc/issues/9020 > > Updating pandoc to 3.1.7 or newer should resolve this issue. Thanks for the bugreport. Most of pandoc functionality is handled by a Haskell library which is packaged separately. This issue is already reported there, but the bugreport is not tagged as affecting this package. With this message will (if I cast the runes correctly) reassign and merge this bugreport with bug#1053777 and mark it as affecting the pandoc package. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Quoting Renzo Davoli (2024-01-09 12:27:19) > The commit should be the following one: Please drop me as cc from this non-bugtracker conversation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Quoting Scott Talbert (2024-01-06 22:30:23) > On Sat, 6 Jan 2024, Jonas Smedegaard wrote: > > > Quoting Scott Talbert (2024-01-05 15:13:08) > >> On Fri, 5 Jan 2024, Renzo Davoli wrote: > > > > [ discussion about bug handling snipped ] > > > > Please use the Debian bugtracker for issues with Debian packages. > > Meh, I'm fine with discussion here, too. The team-maintained packages all > go to the other mailing list, so I'm unlikely to be notified about those > bugs, unless I poll the BTS. Are you saying that the reason you didn't respond to my bugreport about this very issue earlier is that you are not subscribed to receive bugreports? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Quoting Scott Talbert (2024-01-05 15:13:08) > On Fri, 5 Jan 2024, Renzo Davoli wrote: [ discussion about bug handling snipped ] Please use the Debian bugtracker for issues with Debian packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Quoting Renzo Davoli (2024-01-05 12:15:07) > Thank you for your prompt answers. Please use the Debian bugtracker for issues with Debian packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Quoting Scott Talbert (2024-01-01 21:17:01) > On Mon, 1 Jan 2024, Renzo Davoli wrote: > > > Dear debian-haskell maintainers, > > > >The latest Debian SID package is v. 3.0.1 while pandoc > > upstream has already > > released 3.1.11. > > > > I am using pandoc to generate man pages in several projects (and Debian > > packages). > > https://qa.debian.org/developer.php?login=virtualsquare%40cs.unibo.it > > > > Unfortunately man pages created by pandoc < 3.1.7 are incompatible with > > latest groff. > > See: https://github.com/jgm/pandoc/issues/9020 > > > > Lintian complaints for man pages generated by pandoc < 3.1.7. > > > > Have you planned to upgrade pandoc any time soon? > > The Haskell Team generally tracks a Stackage LTS release. Currently, we > are tracking LTS 21.16, which contains (haskell-)pandoc 3.0.1. Since > haskell-pandoc is close to a leaf package, it should likely be possible to > update it without breaking anything else. I'll take a look at updating > it. > > @Jonas, what coordination is needed with you / src:pandoc, since you seem > to be keeping the versions aligned - do we need to let you know ahead of > time, or just do it and let you know? Please let's coordinate in bug#1057852 where I laid out a proposed plan forward - if you approach that plan conservatively then no need to warn me ahead, but if you choose to upgrade dependencies more aggressively then I would appreciate we discussing it first. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it possible to update pandoc, please?
Hi Renzo, Quoting Renzo Davoli (2024-01-01 20:11:07) > Dear debian-haskell maintainers, I recommend to discuss this in bugreports whenever possible, and the issues you raise here seem to easily fit into two bugreports: > The latest Debian SID package is v. 3.0.1 while pandoc > upstream has already > released 3.1.11. Generally upgrading pandoc to a newer upstream release is tracked at bug#1057852. > I am using pandoc to generate man pages in several projects (and Debian > packages). > https://qa.debian.org/developer.php?login=virtualsquare%40cs.unibo.it > > Unfortunately man pages created by pandoc < 3.1.7 are incompatible with > latest groff. > See: https://github.com/jgm/pandoc/issues/9020 Specifically improving Pandoc related to generating man pages is tracked at bug#1053777. Yes, one way to *solve* that bug is by upgrading pandoc generally, but the more specific the issue, the more likely it is possible to cherry-pick a bugfix, in case generally upgrading is too complex to do quickly. > Lintian complaints for man pages generated by pandoc < 3.1.7. It is helpful if you can check if the complaints are all directly related to the issue reported in bug#1053777, and if not then file a separate bugreport for each specific issue you identify. Please notice when filing bugreports that they should be filed against src:haskell-pandoc (i.e. the source package for the main Pandoc library, not the binary package for the pandoc executable binary). Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1059146: pandoc produces html5 that gives lintian errors
Control: reassign -1 libghc-pandoc-dev Quoting Andreas Rönnquist (2023-12-20 14:35:09) > Pandoc produces html5 that gives lintian errors Technically the Debian package "pandoc" now (since v3) is just a thin wrapper around separately packaged library package "libghc-pandoc-dev" which is what causes the lintian error. Reassigning accordingly. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Build failed for haskell-lua on ppc*
Quoting Ilias Tsitsimpis (2023-11-29 08:43:13) > Hi Scott, > > On Tue, Nov 28, 2023 at 12:37PM, Scott Talbert wrote: > > On Mon, 27 Nov 2023, Scott Talbert wrote: > > > > > Hey Ilias, > > > > > > Have you looked at all at the build failure for haskell-lua on ppc? It > > > is segfaulting during the tests. Seems likely it is a GHC problem as > > > the older version of haskell-lua (that built successfully with GHC 9.0) > > > also segfaults with GHC 9.4. I wonder if it is possibly related to that > > > other powerpc issue you were investigating with bytestring-lexing? > > > > Never mind, I see there's already another upstream GHC issue for this that > > you've engaged with. > > Yes, unfortunately this is a different issue > https://gitlab.haskell.org/ghc/ghc/-/issues/23034. I haven't tested > whether the fix for the bytestring-lexing bug helps with haskell-lua, > but the two bugs seem different. > > Unfortunately no-one has worked on this for quite some time. For now, I > propose we disable Lua support for Pandoc on ppc64el. Fedora has done > the same thing. Please file as bugreport against pandoc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1053686: pandoc: cannot fulfill the build dependencies
Quoting Scott Talbert (2023-11-25 19:09:39) > On Thu, 23 Nov 2023, Jonas Smedegaard wrote: > > > Quoting Ilias Tsitsimpis (2023-11-23 21:10:36) > >> On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: > >>> On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: > >>>> Quoting John MacFarlane (2023-11-16 19:25:17) > >>>>> Removing lua support would be most unfortunate! If you need help from > >>>>> upstream in getting things to work, let me know. > >>>> > >>>> I agree: Pandoc with its core scripting language disabled is a severely > >>>> crippled Pandoc. > >>> > >>> Understood, but I am not really sure how to move forward, since Pandoc > >>> doesn't fully support the latest Stackage LTS. I can help with > >>> packaging/upgrade libraries if you can provide the right set of > >>> libraries we need. > >> > >> I uploaded the following packages: > >> > >> * haskell-hslua-cli_v1.3.0-1, > >> * haskell-hslua-module-doclayout_v1.1.0-1 > >> * haskell-hslua-module-zip_v1.1.0-1 > >> > >> I believe the next step is to update pandoc to 3.0.1, so we can then > >> package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. > >> > >> Jonas, how can I help move this forward? Pandoc is the last blocker to > >> finish the Haskell transition. > > > > I think this will be the best way forward: > > > > Haskell team introduces new source package haskell-pandoc. > > > > When available, I can build package pandoc depending on it. > > > > I really don't like breaking upstream project pandoc into two Debian > > source packages like that, but I don't have the energy at the moment to > > try fix dh-haskell (which I suspect will be similar work as I am doing > > to dh-cargo currently). > > I'm working on this (packaging haskell-pandoc). Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1053686: pandoc: cannot fulfill the build dependencies
Quoting Ilias Tsitsimpis (2023-11-23 21:10:36) > On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: > > On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: > > > Quoting John MacFarlane (2023-11-16 19:25:17) > > > > Removing lua support would be most unfortunate! If you need help from > > > > upstream in getting things to work, let me know. > > > > > > I agree: Pandoc with its core scripting language disabled is a severely > > > crippled Pandoc. > > > > Understood, but I am not really sure how to move forward, since Pandoc > > doesn't fully support the latest Stackage LTS. I can help with > > packaging/upgrade libraries if you can provide the right set of > > libraries we need. > > I uploaded the following packages: > > * haskell-hslua-cli_v1.3.0-1, > * haskell-hslua-module-doclayout_v1.1.0-1 > * haskell-hslua-module-zip_v1.1.0-1 > > I believe the next step is to update pandoc to 3.0.1, so we can then > package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. > > Jonas, how can I help move this forward? Pandoc is the last blocker to > finish the Haskell transition. I think this will be the best way forward: Haskell team introduces new source package haskell-pandoc. When available, I can build package pandoc depending on it. I really don't like breaking upstream project pandoc into two Debian source packages like that, but I don't have the energy at the moment to try fix dh-haskell (which I suspect will be similar work as I am doing to dh-cargo currently). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1053686: pandoc: cannot fulfill the build dependencies
Quoting John MacFarlane (2023-11-16 19:25:17) > Removing lua support would be most unfortunate! If you need help from > upstream in getting things to work, let me know. I agree: Pandoc with its core scripting language disabled is a severely crippled Pandoc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1053686: pandoc: cannot fulfill the build dependencies
Quoting Paul Gevers (2023-11-16 11:22:45) > On Thu, 12 Oct 2023 06:36:05 +0200 Jonas Smedegaard wrote: > > Quoting Scott Talbert (2023-10-12 02:33:45) > > > It looks like pandoc can be updated to v3.0.1 and be compatible with the > > > dependencies that are in unstable currently (LTS 21). Can you please let > > > us know if there are any dependencies still missing? > > > I will look at it soon - probably this upcoming weekend. > > Is there any progress with fixing this bug? It seems that this issue is > one of the last blocking issues in the haskell transition. src:pandoc is > a key package, we can't easily remove it from testing to "fix" the blockage. Thanks for pinging/nudging, Paul. Upstream project has restructured to now be organized as multiple projects to be built as dependencies of each other. I had hoped to be able to orchestrate such chain-of-builds internally in the single source package, but the Haskell build helper tools seem to be in too bad shape for that: Apparently all Haskell packages use CDBS which is quite cumbersome to use for "looping" subtasks, and both of the two available non-CDBS debhelper tools existing in Debian are broken. I therefore give up on that approach, and see no other way forward than to introduce the libraries of Pandoc as a new source package, and then have the existing src:pandoc package depend on that to build the binary. I will now file an RFP for that new dependent package, in the hope that the Haskell team can adopt maintenance of that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Haskell transition (LTS 21.16)
Hi Ilias (and cc'ing Debian Haskell Group), Quoting Ilias Tsitsimpis (2023-11-01 14:47:00) > Hi Jonas, > > We are currently working on a Haskell transition (we are targeting > Stackage LTS 21.16) and as part of that, the following packages need > an update: > > * haskell-hsyaml needs an update to 0.2.1.2 > * haskell-intern needs an update to 0.9.5 > * pandoc-sidenote needs a sourceful upload for new haddock interface > * pandoc needs an update to 3.0.1 > > I believe all of the build-dependencies should now be available, but I > have not tested this. The urgent one of course (in order to complete > this transition) is pandoc. > > Can you please try to update pandoc, and let me know if there are any > dependencies missing that we should package as part of the Debian > Haskell Group? I will try to package them ASAP. Pandoc has restructured its source to require compilation in multiple stages. Packaging is already relatively complex, and I expect handling multi-staged building with CDBS to become overly complex. Therefore I have tried - using some of the other far simpler packages as tests - to move from CDBS to dh-haskell. But have not yet succeeded in that. It would be helpful if someone can point to a Debian package succesfully packaging a Haskell library using dh-haskell and without CDBS. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1053686: pandoc: cannot fulfill the build dependencies
Quoting Scott Talbert (2023-10-12 02:33:45) > It looks like pandoc can be updated to v3.0.1 and be compatible with the > dependencies that are in unstable currently (LTS 21). Can you please let > us know if there are any dependencies still missing? Exciting! I will look at it soon - probably this upcoming weekend. Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1041976: pandoc: CVE-2023-35936
Quoting Guilhem Moulin (2023-07-25 23:46:17) > On Tue, 25 Jul 2023 at 14:39:29 +0200, Jonas Smedegaard wrote: > > I have no objections at all - on the contrary: Thanks! > > > > I will have a look at applying the patch to trixie, then - since there > > is unfortunately little hope that the whole Haskell stack will get > > upgrading any time soon, so wi can have a more modern Pandoc. > > Thanks for the quick fix! Filed #1042057 resp. #1042058 for 2.9.2.1-1+deb11u1 > resp. 2.17.1.1-2~deb12u1. You'll find the branches and tags at > https://salsa.debian.org/lts-team/packages/pandoc.git . Easy for me when you handed it on a silverplate like that. :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1041976: pandoc: CVE-2023-35936
Quoting Guilhem Moulin (2023-07-25 13:34:52) > The following vulnerability was published for pandoc. > > CVE-2023-35936[0]: > | Starting in version 1.13 and prior to version 3.1.4, Pandoc is > | susceptible to an arbitrary file write vulnerability, which can be > | triggered by providing a specially crafted image element in the input > | when generating files using the `--extract-media` option or outputting > | to PDF format. This vulnerability allows an attacker to create or > | overwrite arbitrary files on the system, depending on the privileges of > | the process running pandoc. It only affects systems that pass untrusted > | user input to pandoc and allow pandoc to be used to produce a PDF or > | with the `--extract-media` option. […] Note that the `--sandbox` > | option, which only affects IO done by readers and writers themselves, > | does not block this vulnerability. > > I discovered that the upstream fix was incomplete while backporting it > to buster (LTS). Reported the finding upstream who promptly fixed it in > 3.1.6 [1]. Another CVE ID was assigned for this, namely CVE-2023-38745 [2]. > > The Security Team decided not to issue a DSA for these vulnerabilities, > but given they're about to be patched in buster it makes sense to patch > other suites, too. Please consider MR !3 for unstable: > https://salsa.debian.org/haskell-team/pandoc/-/merge_requests/3 . > debdiff attached for convenience. > > I've also prepared (and tested) a fix for bullseye [3] which I'm planing > to submit to -pu once sid is patched. Also planing to rebuild the > targeted fix for bookworm and submit it to s-pu. Let me know if you > object :-) I have no objections at all - on the contrary: Thanks! I will have a look at applying the patch to trixie, then - since there is unfortunately little hope that the whole Haskell stack will get upgrading any time soon, so wi can have a more modern Pandoc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Two different Debian Haskell Group maintainer addresses
Quoting Sven Bartscher (2022-11-25 13:02:44) > TL;DR if you think changing the maintainer addresses of your packages > helps you deal with them, go for it, but try not to take it as a reason > to reduce the ongoing collaboration with the rest of the team. I am not planning on _reducing_ my attention to pandoc or other Haskell-based packages that I am involved in maintaining. I am fine leaving the Maintainer field as-is, but that's kinda bogus and confusing. I am not fine _expanding_ my involvement in the Haskell team, which is the reason I suggest a third option of formally moving "my" packages out of the Haskell team, and then continue the kind of casual coordination we've done in the past also. My question here is if some in the team think I am missing something and moving formally out of the Haskell team effectively means loosing out on some maintenance work I am unaware of. Or perhaps that the better solution is to change maintainer field but *not* subscribe to the list (which seems wrong to me, but maybe someone has experience that bugreports are also sent to Uploaders so it doesn't matter much). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Two different Debian Haskell Group maintainer addresses
Quoting Adrian Bunk (2022-11-24 09:27:39) > I just noticed: > https://qa.debian.org/developer.php?email=debian-haskell%40lists.debian.org > https://qa.debian.org/developer.php?email=pkg-haskell-maintainers%40lists.alioth.debian.org > > It seems Jonas is using a different maintainer address for packages than > other team members? > > This is not a serious or urgent problem, but e.g. looking at all bugs > in packages maintained by pkg-haskell-maintain...@lists.alioth.debian.org > in the BTS[1] currently misses bugs in some packages like pandoc. Hmm, I guess that explains how I have not been bombarded with Haskell packaging noise till now. How do others handle that? I mean, I would obviously like to receive bugreports for pandoc, but opening a firehose for all Haskell packages will mean that I am quite likely to miss relevant posts, since I am not really involved in most work in the Haskell team. Perhaps even framing it like that as "I don't really care about teamwork activities" is an indication that I should move my few Haskell packages out of the team. What do others think? Are there benefits for the team in having me here, with the way I do only very focused work on few packages? Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1023149: pandoc: diff for NMU version 2.17.1.1-1.1
Quoting Scott Talbert (2022-11-24 03:00:41) > On Sat, 19 Nov 2022, Adrian Bunk wrote: > > > Control: tags 1023149 + patch > > Control: tags 1023149 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for pandoc (versioned as 2.17.1.1-1.1) and uploaded > > it to DELAYED/15. Please feel free to tell me if I should cancel it. > > Can this NMU be accepted ASAP? > > Assuming I'm reading excuses correctly, I believe this is preventing a > massive number of haskell packages from migrating to testing. I welcome this bugfix and agree: @Adrian, please release it without further delay. Unfortunately I cannot take over and release now myself, as my GPG key has expired so I cannot do package uploads until the next batch update of the keyring data (which was estimated to happen two days ago, so will probably happen soonish). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
pandoc 2.18 or 2.19
Hi, Pandoc 2.17.1.1 has now entered testing - great! Thanks to everyone involved in making that happen! Newest Pandoc is 2.19.2 - would be cool if we could get (closer to) there before the Freeze. Here are the next batches of changes that would be needed: * upgrade to 2.18 + citeproc >= 0.7 && < 0.8 + doclayout >= 0.4 && < 0.5 + hslua-module-doclayout>= 1.0.4&& < 1.1 + texmath >= 0.12.5 && < 0.12.6 * upgrade to 2.19 + citeproc >= 0.8.0.1 && < 0.9 + gridtables>= 0.0.2&& < 0.1 + hslua-aeson >= 2.2.1&& < 2.3 + pandoc-lua-marshal>= 0.1.7&& < 0.2 + texmath >= 0.12.5.1 && < 0.12.6 Also, in principle unrelated to above, this would be beneficial: * use Lua 5.4 (not Lua 5.3) when needed Haskell libraries are in Debian: + hslua >= 2.2.1&& < 2.3 Would be nice if someone in the Haskell team could do the above. NB! Please do *not* upload a Pandoc without coordinating with me. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.
Quoting Johannes Schauer Marin Rodrigues (2022-09-03 17:37:29) > Quoting Jonas Smedegaard (2022-09-03 16:54:53) > > If you want to explore stepwise what is happening between your > > > > echo ".. code-block:: none" | pandoc -o out.tex -frst > > > > and my > > > > echo ".. code-block:: none" | pandoc -o out.pdf -frst > > > > then you are probably helped by addding option "--standalone": > > > > echo ".. code-block:: none" | pandoc -o out.tex -frst --standalone > > Bingo! Using the --standalone option to pandoc indeed made it generate the > definition for the Highlighting and Verbatim environments. > > Is there a way to tell pandoc to just give me the preamble > that --standalone produces so that nothing breaks the next > time pandoc is updated? There is no command-line option for pandoc to get more finegrained templating components. If you want to programmatically query in more detail, then you need to interact with the underlying Haskell library "skylighting" as mentioned in my previous post (which it seems I accidentally didn't cc you - sorry about that!). > Anyways, not pandoc's fault, so closing this bug. Happy that it got solved. Have a nice weekend! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.
Control: tags -1 +unreproducible
Quoting Jonas Smedegaard (2022-09-03 16:21:21)
> Quoting Johannes Schauer Marin Rodrigues (2022-09-03 15:35:36)
> > so if you run this:
> >
> > echo ".. code-block:: none" | pandoc -o out.tex -frst
> >
> > then with the old pandoc 2.9.2.1 you get:
> >
> > \begin{verbatim}
> > \end{verbatim}
> >
> > and with pandoc 2.17.1.1 you get:
> >
> > \begin{Shaded}
> > \begin{Highlighting}[]
> > \end{Highlighting}
> > \end{Shaded}
>
> Thanks a lot - this makes it much easier to examine the issue further!
...but while the above minimal command demonstrates that "Shaded" gets
introduced in intermediary LaTeX code, this slightly different command
to generate a PDF from that same intermediary LaTeX code does not fail:
echo ".. code-block:: none" | pandoc -o out.pdf -frst
I tested in a somewhat clean sid environment with this prepation:
apt --no-install-recommends install pandoc texlive-latex-recommended lmodern
> > so for this to work with pandoc 2.17.1.1 we need some usepackage for
> > the Shaded environment.
I guess (but again I have *not* looked at your original external code,
so really I am only guessing here!) that the real issue might be that a
custom template is used and that custom template needs to be updated to
match newer pandoc processing.
To demonstrate that this is a bug in pandoc I will need to be able to
trigger it with a minimal failing code example.
If you agree that the bug may be in some custom template needing update,
then you can probably find help in comparing the output from older and
newer pandoc of this command:
pandoc --print-default-template latex
If you want to explore stepwise what is happening between your
echo ".. code-block:: none" | pandoc -o out.tex -frst
and my
echo ".. code-block:: none" | pandoc -o out.pdf -frst
then you are probably helped by addding option "--standalone":
echo ".. code-block:: none" | pandoc -o out.tex -frst --standalone
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.
Quoting Johannes Schauer Marin Rodrigues (2022-09-03 15:35:36)
> Quoting Jonas Smedegaard (2022-09-03 11:41:22)
> > It would be helpful if you could isolate the problem, so that it is
> > possible to replicate with as minimal as possible code besides
> > Pandoc.
>
> so if you run this:
>
> echo ".. code-block:: none" | pandoc -o out.tex -frst
>
> then with the old pandoc 2.9.2.1 you get:
>
> \begin{verbatim}
> \end{verbatim}
>
> and with pandoc 2.17.1.1 you get:
>
> \begin{Shaded}
> \begin{Highlighting}[]
> \end{Highlighting}
> \end{Shaded}
Thanks a lot - this makes it much easier to examine the issue further!
> so for this to work with pandoc 2.17.1.1 we need some usepackage for
> the Shaded environment.
>
> So lets see how to fix this from the latex side. You pointed out that
> the Shaded environment comes from framed.sty, so we try:
>
> \documentclass{article}
> \usepackage{framed}
> \begin{document}
> \begin{Shaded}
> \begin{Highlighting}[]
> foobar
> \end{Highlighting}
> \end{Shaded}
> \end{document}
>
> But we still get:
>
> ! LaTeX Error: Environment Shaded undefined.
>
> So how do I prepare my latex that was generated by recent pandoc so
> that it works?
One extra clue I just found is that apparently the tex chunk involving
"Shading" is not part of Pandoc templates but injected by Haskell
library skylighting:
https://github.com/Wandmalfarbe/pandoc-latex-template/issues/209#issuecomment-744068500
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.
Quoting Johannes Schauer Marin Rodrigues (2022-09-03 11:13:47) > Quoting Jonas Smedegaard (2022-09-03 10:59:04) > > Quoting Johannes Schauer Marin Rodrigues (2022-09-03 06:47:48) > > > since pandoc 2.17.1.1-1, the latex generated from rst by [this script] > > > fails to build with: > > > > > > [14] [15] [16] > > > Chapter 5. > > > (/usr/share/texlive/texmf-dist/tex/latex/microtype/mt-cmr.cfg) > > > Overfull \hbox (15.37852pt too wide) in paragraph at lines 251--258 > > > \TU/Inter(0)/m/n/10 for your computer to execute, but also to write > > > programs (s > > > cripts) > > > [17] > > > > > > ! LaTeX Error: Environment Shaded undefined. > > > > Please tell which texlive-* packages you have installed. > > > > Pandoc can translate between many different formats, and some of them > > require additional packages that are only suggested (to not pull in > > gigantic amounts not needed by all Pandoc users). > > > > Quick online search seems to indicate that "Environment Shaded" is part > > of LaTeX file "framed.dty", and "apt-file search /framed.sty" indicates > > that that file is provided by Debian package texlive-latex-extra - so > > please check that you have that package installed, and if not try install it > > and report back here if that helped. > > thanks for looking into this! > > I sent you a script that you can use to reproduce the problem in my initial > mail. If you grep in that mail for texlive-latex-extra you will see that yes, > it is installed. True, I didn't inspect your script. It would be helpful if you could isolate the problem, so that it is possible to replicate with as minimal as possible code besides Pandoc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.
Hi Josch, Quoting Johannes Schauer Marin Rodrigues (2022-09-03 06:47:48) > since pandoc 2.17.1.1-1, the latex generated from rst by [this script] > fails to build with: > > [14] [15] [16] > Chapter 5. > (/usr/share/texlive/texmf-dist/tex/latex/microtype/mt-cmr.cfg) > Overfull \hbox (15.37852pt too wide) in paragraph at lines 251--258 > \TU/Inter(0)/m/n/10 for your computer to execute, but also to write > programs (s > cripts) > [17] > > ! LaTeX Error: Environment Shaded undefined. Please tell which texlive-* packages you have installed. Pandoc can translate between many different formats, and some of them require additional packages that are only suggested (to not pull in gigantic amounts not needed by all Pandoc users). Quick online search seems to indicate that "Environment Shaded" is part of LaTeX file "framed.dty", and "apt-file search /framed.sty" indicates that that file is provided by Debian package texlive-latex-extra - so please check that you have that package installed, and if not try install it and report back here if that helped. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Jonas Smedegaard (2022-08-08 20:23:48) > Quoting Scott Talbert (2022-08-08 20:02:13) > > On Wed, 8 Jun 2022, Robert Greener wrote: > > > On Sun, 2022-06-05 at 17:31 +0200, Jonas Smedegaard wrote: > > >> Quoting Jonas Smedegaard (2022-05-30 15:40:57) > > >>> Quoting Robert Greener (2022-05-30 15:20:34) > > >>>> On Sat, 2022-05-07 at 19:09 +0100, Robert Greener wrote: > > >>>>>> I would like to update some packages so that pandoc can be > > >>>>>> updated. [...] > > >> Please note that if you choose to upgrade pandoc-types *before* > > >> releasing current updates to unstable, then risk is higher that > > >> we end in a more complicated situation. Your choice. > > > > > > I'll leave it until its in unstable. I now found time to examine the situation more closely, and I see that you chose upgrade pandoc-types and many other packages, which in turn requires upgrading pandoc further, and that requires (surprisingly only) one additional package: pandoc-lua-marshal >= 0.1.7 && < 0.2. Please tell when that library is in Debian, as only then I can (hopefully) upgrade pandoc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Scott Talbert (2022-08-08 20:02:13) > On Wed, 8 Jun 2022, Robert Greener wrote: > > > Hi Jonas, > > > > On Sun, 2022-06-05 at 17:31 +0200, Jonas Smedegaard wrote: > >> Quoting Jonas Smedegaard (2022-05-30 15:40:57) > >>> Quoting Robert Greener (2022-05-30 15:20:34) > >>>> On Sat, 2022-05-07 at 19:09 +0100, Robert Greener wrote: > >>>>>> I would like to update some packages so that pandoc can be > >>>>>> updated. > >>>>>> > >>>>>> /Lots/ of packages would need to be updated to update pandoc > >>>>>> to its > >>>>>> latest upstream (2.18). It is currently on 2.9.2.1. > >>>>>> > >>>>>> To make the task simpler, I intend to update the dependencies > >>>>>> so that > >>>>>> it can be bumped to 2.10.1, and then keep working up. > >>>> Jonas - Once haskell-commonmark-pandoc has been uploaded by Scott > >>>> & > >>>> gone through the NEW queue, you should have enough to upgrade > >>>> pandoc to > >>>> 2.10.1. Could you put this in experimental & I will update hakyll > >>>> and > >>>> patch patat & then everything can be moved to unstable. > >>> > >>> Yes, sounds like I have plenty to work with now. > >> > >> Pandoc 2.10 is now succesfully built in experimental. > > > > Excellent -- thanks! > > > >> Feel free to release dependency updates for that to unstable, then I > >> will release pandoc 2.10 to unstable as well. > >> > >> When haskell-commonmark-pandoc enters experimental I will look into > >> upgrading pandoc to 2.10.1. > >> > >> When haskell-pandoc-types is upgraded to 1.23 then I will look into > >> upgrading pandoc to 2.11 or newer... > > > > > > I'm away for the next few weeks. When I'm back I'll upgrade the few > > things that depend on pandoc and then it can all be moved. Hopefully, > > haskell-commonmark-pandoc will be in experimental by the time I'm back. > > You may want to follow the ITP bug (#1011459) so you get notified when > > it's in experimental. > > > >> Please note that if you choose to upgrade pandoc-types *before* > >> releasing current updates to unstable, then risk is higher that we > >> end > >> in a more complicated situation. Your choice. > > > > I'll leave it until its in unstable. > > FYI - I *think* when the current round of packages (hslua-module-path, > hslua-module-version, lpeg, pandoc-lua-marshal) clears NEW, it should be > possible to update pandoc in unstable. Exciting! Thanks for the heads up! I did notice the bug closures - I have a newer Pandoc release prepared and will try it out soon :-D - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#979124: Debian pandoc situation worsens...
Hi xx27xx, Quoting copropriete27ruemo...@gmail.com (2022-08-06 13:34:29) > Pandoc is now at 2.19, while Debian is still at 2.9.2.1 (except for > experimental, which is at 2.10...). [non-Debian details snipped] > Can something be done to alleviate the problem ? You can join the Haskell team, and help add/update needed packages. Thanks in advance for your help, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]
Quoting Eric Marsden (2022-07-24 16:06:41) > Just to note that this issue has appeared again. pandoc-sidenote version > 0.22.1.0-1+b1 is built against pandoc-types version [1,22,2], but the > versions of pandoc available are built against lower versions ([1,21] > for the version in experimental, [1,20] for the version in unstable). > > Perhaps a simple solution for this problem would be to merge the two > packages (bundle pandoc-sidenote together with pandoc)? Thanks for noting this: It was buggy implementation of resolving and declaring versioned dependency on virtual package pandoc-abi (was wrongly missing version). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Jonas Smedegaard (2022-05-30 15:40:57) > Quoting Robert Greener (2022-05-30 15:20:34) > > On Sat, 2022-05-07 at 19:09 +0100, Robert Greener wrote: > > > > I would like to update some packages so that pandoc can be updated. > > > > > > > > /Lots/ of packages would need to be updated to update pandoc to its > > > > latest upstream (2.18). It is currently on 2.9.2.1. > > > > > > > > To make the task simpler, I intend to update the dependencies so that > > > > it can be bumped to 2.10.1, and then keep working up. > > Jonas - Once haskell-commonmark-pandoc has been uploaded by Scott & > > gone through the NEW queue, you should have enough to upgrade pandoc to > > 2.10.1. Could you put this in experimental & I will update hakyll and > > patch patat & then everything can be moved to unstable. > > Yes, sounds like I have plenty to work with now. Pandoc 2.10 is now succesfully built in experimental. Feel free to release dependency updates for that to unstable, then I will release pandoc 2.10 to unstable as well. When haskell-commonmark-pandoc enters experimental I will look into upgrading pandoc to 2.10.1. When haskell-pandoc-types is upgraded to 1.23 then I will look into upgrading pandoc to 2.11 or newer... Please note that if you choose to upgrade pandoc-types *before* releasing current updates to unstable, then risk is higher that we end in a more complicated situation. Your choice. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Scott Talbert (2022-05-31 15:52:38) > On Tue, 31 May 2022, Jonas Smedegaard wrote: > > > Quoting Scott Talbert (2022-05-31 15:04:51) > >> On Mon, 30 May 2022, Robert Greener wrote: > >> > >>> On Mon, 2022-05-30 at 15:18 +, Robert Greener wrote: > >>>> On Mon, 2022-05-30 at 14:20 +0100, Robert Greener wrote: > >>>>> Thanks to Jonas noticing that some of the lua packages failed to > >>>>> build > >>>>> from source, I checked the one's I've uploaded and a few fail to > >>>>> build > >>>>> also because the locale is not set. > >>>>> > >>>>> Would you be able to upload the following packages[1,2,3] and merge > >>>>> the > >>>>> requests[8,9,10]. > >>>>> > >>>>> All I've done to all of them is add LC_ALL=C.UTF-8 to debian/rules. > >>>>> > >>>>> There are also the two packages mentioned that fixes the bugs Jonas > >>>>> identified. I've included them here for convenience (mentors[4,5], > >>>>> MR[11,12]). These are fixed in the same way (LC_ALL...) > >>>>> > >>>> > >>>> Just hold off on these for a minute Scott if you've seen this... > >>>> > >>>> I've forgot to put a colon between closes and the bug number in the > >>>> changelog so they won't autoclose. > >>> > >>> All OK now. > >> > >> In thinking about the packages that are FTBFS when using LC_ALL=C, this is > >> cause by somewhat of a regression in haskell-devscripts, since the old > >> install recipe used to set LC_ALL=C.UTF-8[1] before running the command > >> where most of these packages are failing (due to the copyright symbol). > >> > >> I'm thinking that rather than update all of these individual packages (and > >> who knows how many more) to set LC_ALL=C.UTF-8, we should restore this > >> setting in haskell-devscripts, and perhaps even set LC_ALL=C.UTF-8 > >> globally in hlibrary.mk? > >> > >> What do you all think? > > > > I think it should be set as minimally as possible - and clearly > > documented. > > > > E.g. only within the rules known to specifically need it, not loaded > > into the global make environment across all make targets. > > That was my initial thinking, too. However, the buildd's set > LC_ALL=C.UTF-8, so wouldn't we want packages built outside the buildd's to > be built consistently? Don't blindly mimic what buildd's do: They do *not* represent Policy! The default environment has locale *undefined*. It is confusing to compose a debian/rules file if defaults changes depending on which build framework you are loading. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Scott Talbert (2022-05-31 15:04:51) > On Mon, 30 May 2022, Robert Greener wrote: > > > On Mon, 2022-05-30 at 15:18 +, Robert Greener wrote: > >> On Mon, 2022-05-30 at 14:20 +0100, Robert Greener wrote: > >>> Thanks to Jonas noticing that some of the lua packages failed to > >>> build > >>> from source, I checked the one's I've uploaded and a few fail to > >>> build > >>> also because the locale is not set. > >>> > >>> Would you be able to upload the following packages[1,2,3] and merge > >>> the > >>> requests[8,9,10]. > >>> > >>> All I've done to all of them is add LC_ALL=C.UTF-8 to debian/rules. > >>> > >>> There are also the two packages mentioned that fixes the bugs Jonas > >>> identified. I've included them here for convenience (mentors[4,5], > >>> MR[11,12]). These are fixed in the same way (LC_ALL...) > >>> > >> > >> Just hold off on these for a minute Scott if you've seen this... > >> > >> I've forgot to put a colon between closes and the bug number in the > >> changelog so they won't autoclose. > > > > All OK now. > > In thinking about the packages that are FTBFS when using LC_ALL=C, this is > cause by somewhat of a regression in haskell-devscripts, since the old > install recipe used to set LC_ALL=C.UTF-8[1] before running the command > where most of these packages are failing (due to the copyright symbol). > > I'm thinking that rather than update all of these individual packages (and > who knows how many more) to set LC_ALL=C.UTF-8, we should restore this > setting in haskell-devscripts, and perhaps even set LC_ALL=C.UTF-8 > globally in hlibrary.mk? > > What do you all think? I think it should be set as minimally as possible - and clearly documented. E.g. only within the rules known to specifically need it, not loaded into the global make environment across all make targets. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies: many packages to upload
Quoting Robert Greener (2022-05-30 15:20:34) > Hi Scott (cc Jonas), > > On Sat, 2022-05-07 at 19:09 +0100, Robert Greener wrote: > > > I would like to update some packages so that pandoc can be updated. > > > > > > /Lots/ of packages would need to be updated to update pandoc to its > > > latest upstream (2.18). It is currently on 2.9.2.1. > > > > > > To make the task simpler, I intend to update the dependencies so > that > > > it can be bumped to 2.10.1, and then keep working up. > > Sorry for the big dump of packages here! > > Thanks to Jonas noticing that some of the lua packages failed to build > from source, I checked the one's I've uploaded and a few fail to build > also because the locale is not set. > > Would you be able to upload the following packages[1,2,3] and merge the > requests[8,9,10]. > > All I've done to all of them is add LC_ALL=C.UTF-8 to debian/rules. > > There are also the two packages mentioned that fixes the bugs Jonas > identified. I've included them here for convenience (mentors[4,5], > MR[11,12]). These are fixed in the same way (LC_ALL...) > > I have also packaged haskell-commonmark-pandoc (mentors[6], MR[13]). > > Finally, now haskell-commonmark-extensions has left the NEW queue, the > correct thing to do is a source-only upload right? If so, I've uploaded > this to mentors[7] and opened a MR[14]. > > Jonas - Once haskell-commonmark-pandoc has been uploaded by Scott & > gone through the NEW queue, you should have enough to upgrade pandoc to > 2.10.1. Could you put this in experimental & I will update hakyll and > patch patat & then everything can be moved to unstable. Yes, sounds like I have plenty to work with now. Also, it just occured to me that independent of fixing the locale bug properly in the packages - which should be done targeted unstable - I am fine doing NMUs targeted experimental with same fix applied. This should not interfere with Scott (or someone else in the team) mentoring your work, Robert. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies
Quoting Robert Greener (2022-05-30 12:48:42) > On Mon, 2022-05-30 at 08:49 +, Robert Greener wrote: > > > I use pbuilder indeed. > > > > > > If the build requires a UTF-8 locale set, then it is wrong to rely > > > on > > > the build environment doing that: The build routines should > > > establish > > > that! > > > > I'm not too sure how to set it to be honest! There is a bug on Ubuntu > > discussing it here[1]. I /think/ (from reading the comments) that it > > isn't possible to set it with pbuilder as it is. However, all > > official > > Debian and Ubuntu builds use C.UTF-8, so it will build okay here. Do > > you think I should raise a bug on the pbuilder package? > > > > Or, do you think it would work if we just set LC_ALL=C.UTF-8 in > > debian/rules? > > Setting LC_ALL does work. I've uploaded the fixes to mentors[1,2] and > opened two MR[3,4] which fixes the FTBFS bugs. For future sake, when you have an idea for a packaging trick but am unsure if it'll work, you might find it helpful to lookup if others are doing something similar - e.g. at https://codesearch.debian.net/ using this search query: LC_ALL=C.UTF-8 path:debian > Would you be okay to merge the requests and upload the packages Jonas? Sorry, I have 20+ years of experience maintaining packages in Debian, with 10+ years doing so with a git-buildpackage-ish workflow, and currently maintain 600+ packages. All my experience is however done project-centric, and I feel totally alienated by the multi-project packaging approach practiced in the Haskell and Rust teams. So no, I cannot (or rather will not invest needed time to learn to) handle multi-project package maintenance. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies
Quoting Robert Greener (2022-05-30 09:05:48) > On Sat, 2022-05-28 at 16:49 +0200, Jonas Smedegaard wrote: > > I noticed that enough packages were avilable in experimental to bump > > pandoc to 2.10. > > You may want to wait until I've done commonmark-pandoc, then you can go > to 2.10.1, up to you though. I am aware - but thanks anyway for mentioning it. If I have the time, I am ok doing it in smaller steps. Doing so also may help progress, as it allows more package updates done in parallel. > > ...or so I thought: > > > > I have now released NMUs of haskell-texmath and > > haskell-hslua-module-system - simple rebuilds against other packages > > only in experimental for now, so I haven't bothered to file a formal > > NMU > > bugreport (but can easily do so if someone wants it). > > > > I wanted to also do NMUs of haskell-hslua-module-text and > > haskell-tasty-lua, but turned out they both are buggy. > > > > Upgrading pandoc now awaits fixing bug#1011989 and #1011992. > > I've just had a quick look at them. Did you build them with pbuilder? I > had an issue with some packages where they would build with debuild but > not pbuilder because pbuilder wasn't using a UTF-8 locale. > > I was just wondering as the error looks like it could be due to that: > commitBuffer: invalid argument (invalid character) I use pbuilder indeed. If the build requires a UTF-8 locale set, then it is wrong to rely on the build environment doing that: The build routines should establish that! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#1011913: haskell-swish: FTBFS: make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25
Control: reassign -1 haskell-swish Control: tag -1 pending Quoting Scott Talbert (2022-05-29 03:48:43) > On Sat, 28 May 2022, Jonas Smedegaard wrote: > > > Control: reassign -1 haskell-devscripts > > Control: retitle -1 haskell-devscripts: DEB_ENABLE_TESTS ignored > > Control: affects -1 haskell-swish > > > > Quoting Lucas Nussbaum (2022-05-26 21:04:50) > >> During a rebuild of all packages in sid, [haskell-swish] failed to build > >> on amd64. > > [...] > >>> Running debian/hlibrary.setup test --builddir=dist-ghc > >>> --show-details=direct > >>> Non-zero exit code 1. > >>> hlibrary.setup: No test suites enabled. Did you remember to configure with > >>> '--enable-tests'? > > > > haskell-swish built successfully when released in January, and contains > > this in debian/rules: > > > >> DEB_ENABLE_TESTS = yes > > > > Perhaps this really is bug#1010179 and the "fix" only papered over the > > underlying problem: @Scott, did you test packages _enabling_ tests or > > only the default of having tests disabled? > > Hi Jonas, > > Actually, it looks like DEB_ENABLE_TESTS=yes had been broken in > haskell-devscripts for quite some time (even before Felix's changes). If > you look at the January build log for haskell-swish, the tests were not > run at that time. In the case of haskell-swish, DEB_ENABLE_TESTS needs to > be defined *before* including hlibrary.mk. After fixing that, it seems > there are some missing test dependencies. Oh! This means haskell-swish hasn't ever run its tests since initial packaging in 2013. Thanks a lot for (indirectly) pointing that out to me. The missing build-dependencies was another bug in my rules file - a silly missing comma in a macro call :-/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies
Quoting Jonas Smedegaard (2022-05-18 11:52:36) > Quoting Robert Greener (2022-05-18 09:09:56) > > On Tue, 2022-05-17 at 19:07 -0400, Scott Talbert wrote: > > > I'm not totally convinced of the need to use experimental for > > > jira-wiki-markup - I think we can just upload it when we update > > > pandoc. > > > So, let's hold off on that for now. > > > > I /think/ the need is because Jonas will need jira-wiki-markup to be > > 1.3.5 (and a few others will need to be updated as well) in order to be > > able to ugrade pandoc to 2.10.1. However, the existing version of > > pandoc depends on an older version of jira-wiki-markup (for example). > > So, during the time between jira-wiki-markup being updated and pandoc > > being updated, it wouldn't be possible to build pandoc from source / > > install pandoc as the version of jira-wiki-markup in the repo would be > > too new for pandoc. > > Exactly ;-) > > Please provide newer jira-wiki-markup in experimental, so that I can > release pandoc to experimental as well - linked against it. > > Then when pandoc succesfully builds in experimental we can release both > to unstable. > > (alternatively, we would need to do *exactly* the same but outside of > Debian, which is less reliable and less transparent) I noticed that enough packages were avilable in experimental to bump pandoc to 2.10. ...or so I thought: I have now released NMUs of haskell-texmath and haskell-hslua-module-system - simple rebuilds against other packages only in experimental for now, so I haven't bothered to file a formal NMU bugreport (but can easily do so if someone wants it). I wanted to also do NMUs of haskell-hslua-module-text and haskell-tasty-lua, but turned out they both are buggy. Upgrading pandoc now awaits fixing bug#1011989 and #1011992. Anyone feel like looking into those? I have already prepared the upgrade of pandoc, so please leave that to me. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1011913: haskell-swish: FTBFS: make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25
Control: reassign -1 haskell-devscripts Control: retitle -1 haskell-devscripts: DEB_ENABLE_TESTS ignored Control: affects -1 haskell-swish Quoting Lucas Nussbaum (2022-05-26 21:04:50) > During a rebuild of all packages in sid, [haskell-swish] failed to build > on amd64. [...] > > Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct > > Non-zero exit code 1. > > hlibrary.setup: No test suites enabled. Did you remember to configure with > > '--enable-tests'? haskell-swish built successfully when released in January, and contains this in debian/rules: > DEB_ENABLE_TESTS = yes Perhaps this really is bug#1010179 and the "fix" only papered over the underlying problem: @Scott, did you test packages _enabling_ tests or only the default of having tests disabled? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies
Quoting Robert Greener (2022-05-18 09:09:56) > On Tue, 2022-05-17 at 19:07 -0400, Scott Talbert wrote: > > I'm not totally convinced of the need to use experimental for > > jira-wiki-markup - I think we can just upload it when we update > > pandoc. > > So, let's hold off on that for now. > > I /think/ the need is because Jonas will need jira-wiki-markup to be > 1.3.5 (and a few others will need to be updated as well) in order to be > able to ugrade pandoc to 2.10.1. However, the existing version of > pandoc depends on an older version of jira-wiki-markup (for example). > So, during the time between jira-wiki-markup being updated and pandoc > being updated, it wouldn't be possible to build pandoc from source / > install pandoc as the version of jira-wiki-markup in the repo would be > too new for pandoc. Exactly ;-) Please provide newer jira-wiki-markup in experimental, so that I can release pandoc to experimental as well - linked against it. Then when pandoc succesfully builds in experimental we can release both to unstable. (alternatively, we would need to do *exactly* the same but outside of Debian, which is less reliable and less transparent) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies - [RFS] haskell-filestore
Quoting Robert Greener (2022-05-10 22:22:16) > How does it work with [packages] that are dependent? > > e.g., jira-wiki-markup-1.3.5 can be uploaded its own but this will > temporarily break pandoc-2.9.2.1 until pandoc is updated to 2.10.1. > However, pandoc cannot be updated until jira-wiki-markup is updated Upload known breaking packages to experimental, and then when dependencies are aligned in experimental upload them all to unstable. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Contributing to pandoc dependencies
Quoting Robert Greener (2022-05-07 20:09:44) > I would like to update some packages so that pandoc can be updated. Great! > Is it okay to move hakyll, hslua, jira-wiki-markup, pandoc, and > pandoc- types to be ahead of the LTS release? I guess your question is mainly tied to maintaining the most-haskell-packages git that I don't understand and therefore cannot give feedback on. Since you mention pandoc itself, I just want to mention that that's tracked in an independent git and I am happy to finalize and release changes to that - or even do all work on that package - as soon as possible to do so (i.e. when dependencies are in Debian experimental or unstable). Thanks for working on this, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: RFS: arbtt/0.11.1-1 [ITA] -- Automatic Rule-Based Time Tracker
Quoting Scott Talbert (2022-05-06 15:27:09) > Note that the DHG doesn't use gbp for packaging - it only maintains > the debian directory in a single git repository for all packages, so > there would be a few changes required to your packaging (e.g. switch > the VCS to the DHG repo, change the Maintainer to the DHG and make > yourself the Uploader, etc.). Some additional information about how > the DHG works here[2]. The above is not accurate: A few packages in the Haskell team are maintained individually git-tracked using git-buildpackage. Possibly only the ~6 packages I am involved with, not sure... > I would be happy to sponsor the upload though if you go this route. ...but if you want someone to sponsor your work, it makes great sense to align with whatever packaging style they are comfortable with, regardless of my nitpicking above. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#997972: haskell-pandoc-citeproc has been deprecated upstream
Quoting Sean Whitton (2022-02-15 07:16:04)
> On Wed 27 Oct 2021 at 07:13pm -04, Louis-Philippe Véronneau wrote:
>
> > Package: src:haskell-pandoc-citeproc
> > Version: 2.9.2.1-1+b2
> > Severity: important
> >
> > Dear maintainers,
> >
> > This project has been deprecated upstream since October 9th 2020
> > [1]. There is a new project called "citeproc" by the same author
> > that replaces it [2].
> >
> > Pandoc version 2.11 (not in Debian yet) now supports the new
> > citeproc invocation ("--citeproc" instead of "--filter
> > pandoc-citeproc") and I believe requires this new binary.
> >
> > Does anyone plan to package the new "citeproc"?
>
> I guess that this will happen when pandoc itself gets updated.
Seems reasonable to me to consider packaging future reverse dependencies
before¹ needed.
Related to this issue, I have gone through the pending releases of
pandoc and gathered when new reverse dependencies become needed:
https://salsa.debian.org/haskell-team/pandoc/-/blob/master/debian/TODO
- Jonas
¹ I am well aware of Haskell team packaging style of doing everything at
once, but personally I do not share that mindset, and I doubt it is
helpful for ftpmasters to release a huge pile at once (but with their
current level of transparency we can unfortunately only speculate about
their needs).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Would you consider updating the ghc package to version 9 for Bookworm (testing) Debian?
Quoting Clint Adams (2022-01-20 15:58:51) > On Thu, Jan 20, 2022 at 02:42:13PM +0100, Marek Ľach wrote: > > I would like to ask if there're any foreseeable plans to possibly update > > the ghc to at least version 9.0.2 > > <https://www.haskell.org/ghc/download_ghc_9_0_2.html> for the testing > > Bookworm distribution? > > My information may be out of date, but I believe that the > current blocker for GHC updates is a build failure on > mipsel: > > https://buildd.debian.org/status/package.php?p=ghc=experimental Not sure, but looks like the error is this: Warning: Coercion: could not fhaddock: out of memory (requested 1048576 bytes) make[3]: *** [compiler/ghc.mk:310: compiler/stage2/doc/html/ghc/ghc.haddock] Error 251 I.e. that something runs out of memory. That experimental build is for GHC 8.10.7. I notice at https://downloads.haskell.org/~ghc/9.0.2/docs/html/users_guide/9.0.2-notes.html that one of the highlights is "Improved compiler performance and memory usage" which sounds promising (but possibly is only compared to 9.0.1, not compared to 8.x). Perhaps someone familiar with GHC could try an experimental build of 9.0.2? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0
Control: clone -1 -2
Control: reassign -1 src:cmark-gfm 0.29.0.gfm.2-1
Control: retitle -1 cmark-gfm: shlibs too relaxed for unstable ABI
Control: affects -1 pandoc blogliterately gitit pandoc-citeproc patat
Control: reassign -2 src:cmark 0.30.2-3
Control: severity -2 important
Control: retitle -2 cmark: shlibs too relaxed for unstable ABI
Quoting Jonas Smedegaard (2022-01-18 18:40:33)
> Quoting gregor herrmann (2022-01-18 18:08:02)
> > While looking at some test issues in libpod-pandoc-perl, I noticed
> > that pandoc looks quite broken in current amd64/sid:
> >
> > % pandoc --version
> > pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0:
> > cannot open shared object file: No such file or directory
> [...]
> > So it looks like pandoc wants libcmark-gfm.so.0.29.0.gfm.0 but
> > libcmark-gfm0 ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an
> > issue in libcmark-gfm0 … Not sure where to fix this.
>
> libcmark-gfm offers an unstable API, so I guess pandoc packaging is to
> blame for having too loose dependency on that inherently untameable
> library package.
>
> Thanks for reporting, Gregor - might be enough to request a binNMU but
> I'd better tighten that dependency, so will do a regular upload.
Hmm - thinking on it, it seems to me that the change really should be in
the libcmark-gfm package - something like this (untested):
override_dh_makeshlibs:
dh_makeshlibs --version-info="libcmark-gfm0 (>= ${DEB_VERSION}),
libcmark-gfm0 (<< ${DEB_VERSION}+)"
Similar is required for the package cmark.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#1003964: pandoc doesn't start: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0
Quoting gregor herrmann (2022-01-18 18:08:02) > While looking at some test issues in libpod-pandoc-perl, I noticed > that pandoc looks quite broken in current amd64/sid: > > % pandoc --version > pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: > cannot open shared object file: No such file or directory [...] > So it looks like pandoc wants libcmark-gfm.so.0.29.0.gfm.0 but > libcmark-gfm0 ships libcmark-gfm.so.0.29.0.gfm.2. Maybe this is an > issue in libcmark-gfm0 … Not sure where to fix this. libcmark-gfm offers an unstable API, so I guess pandoc packaging is to blame for having too loose dependency on that inherently untameable library package. Thanks for reporting, Gregor - might be enough to request a binNMU but I'd better tighten that dependency, so will do a regular upload. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#979124: pandoc: new upstream version
Hi Kenshi, Quoting Kenshi Muto (2021-01-03 06:09:29) > Package: pandoc > Version: 2.9.2.1-1+b1 > Severity: wishlist > > Dear Maintainer, > > Upstream released pandoc 2.11.3.2. Could you consider to update > the package? I would love to upgrade pandoc, but unfortunately it requires doing in lockstep with a slew of Haskell libraries. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debian package of pandoc-crossref filter
Hi Tobias, Quoting Tobias Ruff (2020-12-17 18:12:33) > There is currently no Debian package of pandoc-crossref > (https://github.com/lierdakil/pandoc-crossref) which is available as a > cabal package. > There was a packaging request a while ago on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822173;msg=2 > I have Ubuntu 18.04 installed and I'm actually not sure, whether it's > legitimate to write to the Debian list in this case > Getting the code via cabal is possible, but this version would not work > with the older version of pandoc in Ubuntu/Debian. Moreover, it requires > quite a bit of dependencies for building it, which are not necessary for > a typical end user. > What works pretty well is installing pandoc and pandoc-crossref via > (Ana)conda, but I prefer Debian package to keep my OS installation > clean. > Therefore I tried to generate the package on my own. > Running `cabal-debian` in a clone of the repository works well. > I went on to follow the guidlines on > https://wiki.debian.org/Teams/DebianHaskellGroup/CollabMaint/GettingStarted#Build_the_Debian_Package > (which by the way contain a small typo: "cd DHG_packages/p/haskel-$pkg" > should be "cd DHG_packages/p/haskell-$pkg" - "haskell" with double-l), > but failed due to missing dependencies in the `mk-build-deps` step. > How would you approach this problem? The way forward as a mere user (be that a direct user or indirect via Ubuntu) is to file a bugreport and hope that it doesn't suffer same fate as the older one. Or more elegantly, reopen the old bugreport and posting to it your indication that despite being old there is still some interest in it. Then you locate the addresses of potential maintainers and send them chocolate or beer or money until someone notices and start caring for this packaging request. My address is.. No, just kidding! :-) To do more than just wait, you can join the team (you need not be official Debian member to join!) and help do the packaging yourself. Yes, at first that most likely means packaging an older version which works with the set of Haskell libraries we have currently in Debian, and then when the whole library stack gets upgraded your package (may need renewed packaging tweaks and then) gets upgraded as well. The alternative approach is, as you sort-of say yourself, to bypass Debian and build the package some other way. That might be simpler at first but painful to maintain, or the other way around, or all great - I really don't know, because my interest is the collective Debian way. Hope that helps (a bit), - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#969475: pandoc: New release available
Control: retitle -1 pandoc: does not work with reveal.js 4.x Control: severity -1 minor Hi Thomas, Quoting Thomas Clavier (2020-09-03 17:48:21) > Package: pandoc > Version: 2.9.2.1-1 > Severity: normal > > Dear Maintainer, > > The last version of pandoc work fine with revealjs 4.0 see : > https://github.com/jgm/pandoc/issues/6431 Thanks for your bugreport. Since this is a bugtracker and "New release available" is not a bug, I have taken the liberty of reading your mind regarding what you consider a bug in the Debian packaging of pandoc. If I failed at that (mind-reading is kinda brittle, especially from afar), then please do elaborate what was on your mind. :-) Also, I lowered severity since RevealJS is not in Debian (please consider filing a so-called RFP: see https://www.debian.org/devel/wnpp/#l1 for details on how to that). Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Pandoc update for LTS 16.9
Hi Ilias, Quoting Ilias Tsitsimpis (2020-08-22 11:58:31) > We are now targeting LTS 16.9 in unstable. Could you please update > pandoc to the corresponding version (2.9.2.1)? All the dependencies > should be available. > > Note that base-noprelude is not packaged for Debian. I didn't do so > because it's used only on this version of pandoc and has been removed > from newer versions. You will have to apply this[1] upstream patch. > > [1] https://github.com/jgm/pandoc/commit/a9ef15bbd574b Thanks, compiling now...! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#967901: lower memory usage for riscv build
Quoting Sebastien Bacher (2020-08-04 23:14:50) > Hey Aurélien, Jonas, thanks for the replies > > Le 04/08/2020 à 19:11, Jonas Smedegaard a écrit : > > Closing this bugreport does not imply that conversation is closed, > > only that with the currently presented material there is no further > > action. We can continue the conversation in a "closed" bugreport. > > You are still most welcome to provide more information - e.g. more > > details on why (if so) you think that it is relevant that Debian > > (not only Ubuntu) uses the build flags that you requested. > > > > In addition to the (little) information presented here, I based my > > judgement on some casual conversation on irc. I explicitly asked > > there to please share information in a bugreport but nothing came of > > that. > > Sorry for the lack of informations and the ignorance of the context. > I'm not working on this package, just wanted to see it updated in > Ubuntu so went to do the merge and saw that the only diff we had was > recent and not forwarded to Debian so I did that. Makes sense. Thanks for the additional context. > I'm not familiar with riscv64 nor the difference between the Debian > and the Ubuntu port and why it would fail only in Ubuntu. From what I > can see the build was tried on > https://launchpad.net/ubuntu/+source/pandoc/2.8.1-2ubuntu1 and failed > after 2.5 days without letting a build log. > > Then Dimitri (Cc here now) added a delta to --disable-optimization, > which he had done in a previous upload for armhf/arm64. Since I saw > you basically addressed a similar issue in Debian now with other flag > I though it would make sense to do the same on riscv64. > > The build time are similarly slow on Debian but didn't fail at the end > so maybe the change is wrong there and more details are needed ... > Dimitri could you help there? In my understanding (lacking any evidence, based only on irc chatter), Ubuntu compiles riscv64 in an emulator, not on real hardware. > > Hope that helps. A bit. But yes, if ehat you need is to limit the > > delta of Ubuntu packaging and that alone, then I really am not > > helping here. > I've redone the patch to be an Ubuntu specific rules in debian/rules, > that shouldn't come to much cost to Debian and is quite common in > other packages [1]. If you believe it's wrong and that riscv64 > shouldn't be consider a low memory architecture / you don't want to > carry a rule specific to Ubuntu then it's your choice. It does not help to restructure the patch to only affect Ubuntu, Sorry. The package is maintained in Debian for all users of Debian, which includes derivatives of Debian using the package as-is, or rebuilding from source as-is, or rebuilding from source with patches applied. What is not accepted is maintaining in Debian any patches for downstream-only needs - regardless that others in Debian are willing to do so. > I will try to drop the delta and see if the build still fail and if we > a build log of the error I will expect that to continue to be very slow, due to the build being done on emulated hardware. Whether or not that is acceptable for Ubuntu is a concern internally for that distribution. What makes it a concern worthy of consideration for Debian to maintain is if it is a rumor - i.e. if building on real risc64 hardware is extremely slow. Debian does not yet officially build for riscv64, and I am unaware if the unofficial build is done emulated or not. You might try ask the porters about that. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#967901: lower memory usage for riscv build
Quoting Jonas Smedegaard (2020-08-04 18:17:07) > Control: tags -1 wontfix > > Quoting Sebastien Bacher (2020-08-04 17:29:21) > > Could you add riscv64 to the list of architecture where build needs > > a reduced memory usage? The change has been added to Ubuntu and is > > the only delta between the distribution > > Sorry, no. > > We do not need that in Debian, and I will not carry patches in Debian > unique to downstream derivatives: When a derivative distribution > choose to be different from Debian then it is on them to carry the > burden of maintaining such delta. Let me elaborate a bit, as I imagine that above can easily come across as "shut up and go away" which really isn't what I intended...: Closing this bugreport does not imply that conversation is closed, only that with the currently presented material there is no further action. We can continue the conversation in a "closed" bugreport. You are still most welcome to provide more information - e.g. more details on why (if so) you think that it is relevant that Debian (not only Ubuntu) uses the build flags that you requested. In addition to the (little) information presented here, I based my judgement on some casual conversation on irc. I explicitly asked there to please share information in a bugreport but nothing came of that. Hope that helps. A bit. But yes, if ehat you need is to limit the delta of Ubuntu packaging and that alone, then I really am not helping here. In any case, thanks for filing the bugreport and proposing the patch - please continue to do so, even if this one was turned down: I am not fundamentally against Ubuntu, and I am certainly not the only one in Debian, so there is still hope :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Jonas Smedegaard (2020-07-30 14:56:35) > Quoting Adrian Bunk (2020-07-30 14:50:11) > > The patch below is tested on armel and mipsel. > > > > cu > > Adrian > > > > --- pandoc-2.9.1.1/debian/rules 2020-07-16 18:12:12.0 +0300 > > +++ pandoc-2.9.1.1/debian/rules 2020-07-16 18:13:21.0 +0300 > > @@ -178,8 +178,8 @@ > > DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="+RTS -V0 -RTS" > > > > # Reduce compile-time memory utilization on low-memory architectures > > -ifneq (,$(filter $(DEB_BUILD_ARCH),armel armhf mips mipsel)) > > -DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param > > -optcggc-min-expand=5" > > +ifneq (,$(filter $(DEB_HOST_ARCH),armel armhf hppa mips mipsel)) > > +DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param > > -optcggc-min-expand=10 -O0" > > endif > > > > DEB_ENABLE_TESTS = yes > > Great! > > I would organizxe the options a bit different (e.g. to avoid confusion > over redifining for armhf), but am otherwise happy to proceed with this > unless anyone objects or has other input (@Locusofberg?)... Silly me, I misread the above as an addition (not a replacement), so please ignore my remark about armhf. I'll apply the patch now and release. Thanks, Adrian! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Adrian Bunk (2020-07-30 14:50:11) > The patch below is tested on armel and mipsel. > > cu > Adrian > > --- pandoc-2.9.1.1/debian/rules 2020-07-16 18:12:12.0 +0300 > +++ pandoc-2.9.1.1/debian/rules 2020-07-16 18:13:21.0 +0300 > @@ -178,8 +178,8 @@ > DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="+RTS -V0 -RTS" > > # Reduce compile-time memory utilization on low-memory architectures > -ifneq (,$(filter $(DEB_BUILD_ARCH),armel armhf mips mipsel)) > -DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param > -optcggc-min-expand=5" > +ifneq (,$(filter $(DEB_HOST_ARCH),armel armhf hppa mips mipsel)) > +DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param > -optcggc-min-expand=10 -O0" > endif > > DEB_ENABLE_TESTS = yes Great! I would organizxe the options a bit different (e.g. to avoid confusion over redifining for armhf), but am otherwise happy to proceed with this unless anyone objects or has other input (@Locusofberg?)... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Adrian Bunk (2020-07-16 19:32:41) > On Thu, Jul 16, 2020 at 07:25:28PM +0200, Jonas Smedegaard wrote: > > Control: found -1 > > > > Quoting Adrian Bunk (2020-07-16 17:53:44) > > > On Thu, Jul 16, 2020 at 05:34:46PM +0200, Jonas Smedegaard wrote: > > > > Quoting Adrian Bunk (2020-07-16 17:29:17) > > > > > On Thu, Jul 16, 2020 at 04:02:53PM +0200, Jonas Smedegaard wrote: > > > > > > Quoting Mikolaj Konarski (2020-07-16 15:50:53) > > > > > > > Hi, > > > > > > > > > > > > > > Does disabling optimization help? I have it disabled for > > > > > > > these architectures in haskell-lambdahack and it did help > > > > > > > in that case. > > > > > > > > > > > > I will try. Thanks for the suggestion! > > > > > > > > > > "-O0 -g0" worked for me on armel, I am currently trying on > > > > > mipsel what the minimum required change is. > > > > > > > > As I understand it, "-O0 -g0" is not the most minimally > > > > intrusive, > > > > > > "-O0 -g0" is nearly the biggest possible hammer. > > > > > > It was my starting point for seeing that there is some possible > > > solution available this way. > > > > > > > instead (as I also posted separately in more detail a moment > > > > ago) that is --ghc-options="-optc--param -optcggc-min-expand=5" > > > > > > If that is sufficient it is great. > > > > > > Unless something changed recently no debug info is distributed for > > > Haskell-built binaries, so -g1/-g0 does not actually make anything > > > worse. This is what I am currently trying on eller. > > > > My tweak wasn't adequate. > > > > I am open to suggestions. > > Give me 1-3 days (test builds take time) and I can send a patch. Awesome. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Control: found -1 Quoting Adrian Bunk (2020-07-16 17:53:44) > On Thu, Jul 16, 2020 at 05:34:46PM +0200, Jonas Smedegaard wrote: > > Quoting Adrian Bunk (2020-07-16 17:29:17) > > > On Thu, Jul 16, 2020 at 04:02:53PM +0200, Jonas Smedegaard wrote: > > > > Quoting Mikolaj Konarski (2020-07-16 15:50:53) > > > > > Hi, > > > > > > > > > > Does disabling optimization help? I have it disabled for these > > > > > architectures in haskell-lambdahack and it did help in that > > > > > case. > > > > > > > > I will try. Thanks for the suggestion! > > > > > > "-O0 -g0" worked for me on armel, I am currently trying on mipsel > > > what the minimum required change is. > > > > As I understand it, "-O0 -g0" is not the most minimally intrusive, > > "-O0 -g0" is nearly the biggest possible hammer. > > It was my starting point for seeing that there is some possible > solution available this way. > > > instead (as I also posted separately in more detail a moment ago) > > that is --ghc-options="-optc--param -optcggc-min-expand=5" > > If that is sufficient it is great. > > Unless something changed recently no debug info is distributed for > Haskell-built binaries, so -g1/-g0 does not actually make anything > worse. This is what I am currently trying on eller. My tweak wasn't adequate. I am open to suggestions. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Adrian Bunk (2020-07-16 17:53:44) > On Thu, Jul 16, 2020 at 05:34:46PM +0200, Jonas Smedegaard wrote: > > Quoting Adrian Bunk (2020-07-16 17:29:17) > > > On Thu, Jul 16, 2020 at 04:02:53PM +0200, Jonas Smedegaard wrote: > > > > Quoting Mikolaj Konarski (2020-07-16 15:50:53) > > > > > Hi, > > > > > > > > > > Does disabling optimization help? I have it disabled for these > > > > > architectures in haskell-lambdahack and it did help in that case. > > > > > > > > I will try. Thanks for the suggestion! > > > > > > "-O0 -g0" worked for me on armel, I am currently trying on mipsel what > > > the minimum required change is. > > > > As I understand it, "-O0 -g0" is not the most minimally intrusive, > > "-O0 -g0" is nearly the biggest possible hammer. Ohh, sorry: I totally misread your previous message. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Adrian Bunk (2020-07-16 17:29:17) > On Thu, Jul 16, 2020 at 04:02:53PM +0200, Jonas Smedegaard wrote: > > Quoting Mikolaj Konarski (2020-07-16 15:50:53) > > > Hi, > > > > > > Does disabling optimization help? I have it disabled for these > > > architectures in haskell-lambdahack and it did help in that case. > > > > I will try. Thanks for the suggestion! > > "-O0 -g0" worked for me on armel, I am currently trying on mipsel what > the minimum required change is. As I understand it, "-O0 -g0" is not the most minimally intrusive, instead (as I also posted separately in more detail a moment ago) that is --ghc-options="-optc--param -optcggc-min-expand=5" - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Jonas Smedegaard (2020-07-16 16:02:53) > Quoting Mikolaj Konarski (2020-07-16 15:50:53) > > Hi, > > > > Does disabling optimization help? I have it disabled for these > > architectures in haskell-lambdahack and it did help in that case. > > I will try. Thanks for the suggestion! Looking closer, it seems the better approach is to not disable optimizations completely but instead tune GCC garbage-collection. 5 years ago, Joachim suggested¹ to apply that generally to Haskell build framework but it was suggested that "[t]here are only few Haskell packages with this issue" and apparently it ended there. So I suggest to try change lambdacheck to this: # Reduce compile-time memory utilization on low-memory architectures ifneq (,$(filter $(DEB_BUILD_ARCH),mips mipsel)) DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param -optcggc-min-expand=5" endif Above seems to most common settings. Some has the threshold more relaxed at at 20. For pandoc I now try include armel and armhf, and lower threshold to 5. - Jonas ¹ https://bugs.debian.org/783126#10 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#965121: pandoc: FTBFS on armel, armhf, mipsel: out of memory
Quoting Mikolaj Konarski (2020-07-16 15:50:53) > Hi, > > Does disabling optimization help? I have it disabled for these > architectures in haskell-lambdahack and it did help in that case. I will try. Thanks for the suggestion! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: The NEW queue process (Was: Re: Bug#964983: New Upstream Version)
Quoting Gard Spreemann (2020-07-14 18:04:13) > Hi! > > Barak A. Pearlmutter writes: > > > Sometimes I wonder if Debian needs some serious process analysis and > > restructuring. Should a new library version that happens to cross a major > > version boundary really good though the same extra vetting queue that a new > > browser goes through? > > > > tldr: What have we wrought??? > > I'm sorry for picking up on the discussion on this list, but I do not > feel that I've been a DD for long enough to bring a naive question like > this to d-devel on my own – and since you do bring it up I'm tempted to > ask here. > > I've long wondered about the apparent discrepancy in how the NEW queue > works. On one hand, a new source package can spend months in the NEW > queue for very good reasons, such as checking the legality of > redistributing the package and keeping the namespace sane. Yet once that > hurdle is cleared, the same source package can change radically in its > next upload, which essentially renders the legality checking > pointless. But at the same time, a package that merely bumps a soname or > splits a binary package into two (without even changing the contents) > can spend months in NEW all over again. This seems completely arbitrary > to me, and sounds like a way to overwork the ftpmasters for little real > (legal) gain. > > I have a hard time understanding this discrepancy, but maybe someone can > shed some light on it? Almost every time I've found a process in Debian > tedious or slow, I've learned to appreciate the gains that process > brings that I had previously overlooked. With the NEW queue, I am yet to > understand the rationale. Am I missing something? NEW processing is a volunteer task, which a) requires special knowledge and therefore involves a training process, and b) is not as visibly credited as some other contributions, and c) has a real risk of involving grumpy reactions when rejections are needed. Those features probably discourages quite a few from volunteering to get inolved in that particular task in Debian. Occationally threads in debian-devel discuss ideas to "fix" what is perceived from the outside as technical flaws in the NEW processing, but most of us (me included) can only _guess_ if it is really flaws, because we haven't dived in and learned the details of what the NEW processing really is. Hope that helps (not speed up NEW processing, but understand why it is hard thing to improve on). I can suggest to locate and read some of the previous discussions in debian-devel, and think hard (as it sounds like you already do - thanks!) before starting/rehashing yet again. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Transition, libghc-xmonad-dev
Quoting Adam Sjøgren (2020-07-14 13:53:58) > Jonas writes: > > > Quoting Adam Sjøgren (2020-07-05 17:58:57) > > >> Maybe I should try to get rid of the dependency on Text.Pandoc in > >> xmonad, it is only used to generate the man-page from a markdown file > >> with some keybindings inserted. > > > If xmonad really only use pandoc for translating markdown, then it > > sounds quite sensible to me to try (only) use cmark instead. > > xmonad's GenerateManPage uses Text.Pandoc to convert markdown to both > man (troff) and html, if cmark can do the first conversion as well, your > suggestion sounds like a good idea. Seems that way: Upstream README at https://github.com/jgm/cmark-hs mentions that "[o]utput in HTML, groff man, LaTeX, CommonMark, and a custom XML format is supported." If you are lucky it is an easy patch - possibly also needing slight adjustments to markdown source data to match the stricter CommonMark spec. I no longer use xmonad myself, but remember frm when I did that the biggest frustration was that you'd need a working _development_ environment, and each time Haskell packages went out of sync (using Debian unstable), xmonad was one of the last ones to get back in sync. I imagine that a decoupling from Pandoc might change that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#963128: pandoc: conversion from docbook: missing space between firstname and lastname
Control: tags -1 confirmed Control: found -1 2.8.1-1 Quoting Vincent Lefevre (2020-06-19 13:56:31) > When converting from docbook, a space is missing between the firstname > and the lastname in the generated file: > > >"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;> > > > > Title > > FirstnameLastname > > 1.17 > > > Text. > > > > $ pandoc -s -f docbook manual.xml -t html > [...] > FirstnameLastname > [...] > > $ pandoc -s -f docbook manual.xml -t texinfo > [...] > @author FirstnameLastname > [...] Thanks! Confirmed, also with newer release 2.8.1-1. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#963128: pandoc: conversion from docbook: missing space between firstname and lastname
Quoting Vincent Lefevre (2020-06-19 13:56:31) > Package: pandoc > Version: 2.5-3+b1 > Severity: normal > > When converting from docbook, a space is missing between the firstname > and the lastname in the generated file: > > >"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;> > > > > Title > > FirstnameLastname > > 1.17 > > > Text. > > > > $ pandoc -s -f docbook manual.xml -t html > [...] > FirstnameLastname > [...] > > $ pandoc -s -f docbook manual.xml -t texinfo > [...] > @author FirstnameLastname > [...] > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages pandoc depends on: > ii libatomic1 10.1.0-4 > ii libc62.30-8 > ii libffi7 3.3-4 > ii libgmp10 2:6.2.0+dfsg-6 > ii libpcre3 2:8.39-13 > ii pandoc-data 2.5-3 > ii zlib1g 1:1.2.11.dfsg-2 > > pandoc recommends no packages. > > Versions of packages pandoc suggests: > ii context2020.03.10.20200331-1 > pn ghc > ii groff 1.22.4-5 > ii libjs-mathjax 2.7.8+dfsg-1 > ii librsvg2-bin 2.48.7-1 > pn node-katex > ii nodejs 12.18.0~dfsg-3 > pn pandoc-citeproc > ii perl 5.30.3-4 > pn php > ii python 2.7.17-2 > pn r-base-core > ii ruby 1:2.7+1 > ii texlive-latex-extra2020.20200522-1 > ii texlive-latex-recommended 2020.20200522-1 > ii texlive-luatex 2020.20200522-1 > ii texlive-xetex 2020.20200522-1 > pn wkhtmltopdf > > -- no debconf information > > -- > Vincent Lef�vre - Web: <https://www.vinc17.net/> > 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) > -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#963129: pandoc: conversion from docbook: missing releaseinfo information
Control: tags -1 confirmed Control: found -1 2.8.1-1 Quoting Vincent Lefevre (2020-06-19 13:58:43) > When converting from docbook, releaseinfo is ignored, e.g. on > > >"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;> > > > > Title > > FirstnameLastname > > 1.17 > > > Text. > > > > with: > > pandoc -s -f docbook manual.xml -t html > pandoc -s -f docbook manual.xml -t texinfo Thanks for reporting. I can confirm this, also with freshly released version 2.8.1-1. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Transition, libghc-xmonad-dev
Quoting Adam Sjøgren (2020-07-05 17:58:57) > I'm not sure where to start, or how I help most efficiently with > getting pandoc updated, so xmonad can be. > > Maybe I should try to get rid of the dependency on Text.Pandoc in > xmonad, it is only used to generate the man-page from a markdown file > with some keybindings inserted. If xmonad really only use pandoc for translating markdown, then it sounds quite sensible to me to try (only) use cmark instead. And propose such patch upstream as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Clint Adams (2020-07-13 19:48:57) > On Mon, Jul 13, 2020 at 12:21:22PM +0200, Jonas Smedegaard wrote: > > I will only attempt patching _after_ haskell-doctemplates is installable > > in unstable. > > It's now available on all release architectures but mipsel, mips64el, > and s390x. Thanks. It was however not just rebuilt with up-to-date Haskell but also upgraded, which complicates aligning it with Pandoc. I will try... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Jonas Smedegaard (2020-07-12 17:00:28) > Quoting Jonas Smedegaard (2020-07-12 03:00:41) > > Quoting Sean Whitton (2020-07-12 02:43:02) > > > On Fri 12 Jun 2020 at 10:48PM +02, Jonas Smedegaard wrote: > > > > Recent releases of Pandoc need these: > > > > > > > > * hslua-module-system >= 0.2 && < 0.3 > > > > * tasty-lua >= 0.2 && < 0.3 > > > > > > > > Would be nice if someone in the team could package them. > > > > > > > > NB! Please do *not* upload a Pandoc without coordinating with me. > > > > > > May I ask where you are with pandoc atm? > > > > > > pandoc-citeproc and pandoc-citeproc-preamble are broken and I > > > believe fixing them needs newer pandoc. > > > > I am pretty much same place as last I posted to this thread: Waiting > > for others in the Haskell team to tell me that dependencies have > > become available. > > Above specific dependencies entered unstable earlier today. > > Also haskell-doclayout from NEW is needed for pandoc 2.8.1. > > Also haskell-emojis from NEW is needed for pandoc 2.9.1. > > Also haskell-jira-wiki-markup from NEW is needed for pandoc 2.9.1.1. > > Newer haskell-doclayout 0.3.x is needed for Pandoc 2.9.2. > > Newer haskell-jira-wiki-markup 1.1.3.x is needed for pandoc 2.9.2.1. > > Newer haskell-jira-wiki-markup 1.3.x and haskell-doctemplates 0.8.2.x > is needed for pandoc 2.9.2.1. > > Newer haskell-jira-wiki-markup 1.3.2.x and haskell-hslua 1.1.x and > haskell-pandoc-types 1.21.x is needed for pandoc 2.10. Today haskell-doclayout entered unstable. haskell-doctemplates is currently uninstallable in unstable, however. If someone from the Haskell team can fix haskell-doctemplates to build with current GHC in unstable (maybe requires only a binNMU, I don't know), then I can try patch pandoc 2.8.1 to build with what we have now. I will only attempt patching _after_ haskell-doctemplates is installable in unstable. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Jonas Smedegaard (2020-07-12 03:00:41) > Quoting Sean Whitton (2020-07-12 02:43:02) > > Hello Jonas, > > > > On Fri 12 Jun 2020 at 10:48PM +02, Jonas Smedegaard wrote: > > > > > Hi, > > > > > > Recent releases of Pandoc need these: > > > > > > * hslua-module-system >= 0.2 && < 0.3 > > > * tasty-lua >= 0.2 && < 0.3 > > > > > > Would be nice if someone in the team could package them. > > > > > > NB! Please do *not* upload a Pandoc without coordinating with me. > > > > May I ask where you are with pandoc atm? > > > > pandoc-citeproc and pandoc-citeproc-preamble are broken and I believe > > fixing them needs newer pandoc. > > I am pretty much same place as last I posted to this thread: Waiting > for others in the Haskell team to tell me that dependencies have > become available. Above specific dependencies entered unstable earlier today. Also haskell-doclayout from NEW is needed for pandoc 2.8.1. Also haskell-emojis from NEW is needed for pandoc 2.9.1. Also haskell-jira-wiki-markup from NEW is needed for pandoc 2.9.1.1. Newer haskell-doclayout 0.3.x is needed for Pandoc 2.9.2. Newer haskell-jira-wiki-markup 1.1.3.x is needed for pandoc 2.9.2.1. Newer haskell-jira-wiki-markup 1.3.x and haskell-doctemplates 0.8.2.x is needed for pandoc 2.9.2.1. Newer haskell-jira-wiki-markup 1.3.2.x and haskell-hslua 1.1.x and haskell-pandoc-types 1.21.x is needed for pandoc 2.10. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Sean Whitton (2020-07-12 02:43:02) > Hello Jonas, > > On Fri 12 Jun 2020 at 10:48PM +02, Jonas Smedegaard wrote: > > > Hi, > > > > Recent releases of Pandoc need these: > > > > * hslua-module-system >= 0.2 && < 0.3 > > * tasty-lua >= 0.2 && < 0.3 > > > > Would be nice if someone in the team could package them. > > > > NB! Please do *not* upload a Pandoc without coordinating with me. > > May I ask where you are with pandoc atm? > > pandoc-citeproc and pandoc-citeproc-preamble are broken and I believe > fixing them needs newer pandoc. I am pretty much same place as last I posted to this thread: Waiting for others in the Haskell team to tell me that dependencies have become available. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Ilias Tsitsimpis (2020-06-14 21:11:37) > Hey Jonas, > > On Fri, Jun 12, 2020 at 10:48PM, Jonas Smedegaard wrote: > > Recent releases of Pandoc need these: > > > > * hslua-module-system >= 0.2 && < 0.3 > > * tasty-lua >= 0.2 && < 0.3 > > > > Would be nice if someone in the team could package them. > > It's on the TODO list, will upload them once their build-deps are > available. > > > NB! Please do *not* upload a Pandoc without coordinating with me. > > Of course, I will let you know once it's buildable. Great. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#749891: [Pkg-haskell-maintainers] Bug#749891: pandoc: doesn't support some Unicode characters with PDF output
Quoting Vincent Lefevre (2020-06-12 22:56:50) > Well, I can see that the following issue has been fixed: > > > > * if the character isn't present, it should output an error. > > e.g. I get > > $ pandoc file --pdf-engine=xelatex -o out.pdf > [WARNING] Missing character: There is no ≤ in font > [lmroman10-regular]:mapping=tex-text;! > > So, if something is wrong, at least I know that I need to change > the font. Ohhh, I totally missed that this was an ancient bugreport, so I didn't check if things had improved recently. Yes, as also noted in related https://bugs.debian.org/639139 the error handling has improved over time. :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]
[ sent again, cc the bugreport ] Quoting John MacFarlane (2020-06-12 22:11:39) > I don't understand how this is possible: don't all the > debian packages that depend on pandoc-types get compiled > against the same version of pandoc-types? Evidently not. I was surprised as well. Seems it is because we are in a middle of a recompilation, where this can happen. I.e. it is technically possible to update a subset of libraries without all being recompiled - but if all machinery and checks works as intended such misaligned scenario is not permitted to reach a stable release. For Pandoc, even if it only happens temporarily, it still reveals a problem of the package having an ABI towards filters that is currently not tracked at the Debian packaging level. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
new upcoming Pandoc dependency
Hi, Recent releases of Pandoc need these: * hslua-module-system >= 0.2 && < 0.3 * tasty-lua >= 0.2 && < 0.3 Would be nice if someone in the team could package them. NB! Please do *not* upload a Pandoc without coordinating with me. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#962715: Incompatible API versions: encoded with [1,17,5,4] but attempted to decode with [1,20]
Quoting Eric Marsden (2020-06-12 16:08:52) > Package: pandoc-sidenote > Version: 0.20.0-1 > > When invoking pandoc-sidenote as a pandoc filter, it generates an error > related to "incompatible API versions". > > % pandoc --filter pandoc-sidenote -o /tmp/foo.html foo.md > pandoc-sidenote: Error in $: Incompatible API versions: encoded with > [1,17,5,4] but attempted to decode with [1,20]. > CallStack (from HasCallStack): > error, called at ./Text/Pandoc/JSON.hs:107:64 in > pandoc-types-1.20-Ip2ZGM2tgGt4TDYVgvP7zF:Text.Pandoc.JSON > Error running filter pandoc-sidenote: > Filter returned error status 1 > > > Architecture is amd64. Pandoc version is 2.5-3+b1. Reverting to the > previous version 0.19.0.0-2+b4 works fine. Interesting! Looks like pandoc and pandoc-sidenote was compiled with different versions of pandoc-types, and strongly depend on that being identical at runtime. I will look into having pandoc provide a virtual package indicating its "ABI" of which pandoc-types it was compiled against, and then have pandoc-sidenote depend on that ABI. Thanks for reporting! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure
Control: clone -1 -2 Control: retitle -2 pandoc: please upgrade to 2.4 or newer to support parsing man format Control: severity -2 wishlist Quoting Jonas Smedegaard (2020-05-06 21:14:24) > Quoting James Youngman (2020-05-06 20:43:10) > > It seems to me that that interpretation was rather optimistic (and > > easily falsifiable using the provided reproduction steps): > > > > horizon:~$ rm -f bbcbasic.html; pandoc -f man -s -o bbcbasic.html > > /tmp/minimal_nroff2.1 ; echo exit status $?; ls -l bbcbasic.html > > Unknown reader: man > > exit status 1 > > /bin/ls: cannot access 'bbcbasic.html': No such file or directory Quoting John MacFarlane (2020-05-06 21:50:11) > As you can see from pandoc's changelog, the man reader was only > introduced in version 2.4. You're using an older version, so... Thanks again, John. > > Please reconsider the severity change. Hereby forking the bugreport to separately track upgrading the pandoc package to a version which supports parsing man format. Please do elaborate if you meant differently with your request for severity change. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure
Quoting James Youngman (2020-05-06 20:43:10) > It seems to me that that interpretation was rather optimistic (and > easily falsifiable using the provided reproduction steps): > > horizon:~$ rm -f bbcbasic.html; pandoc -f man -s -o bbcbasic.html > /tmp/minimal_nroff2.1 ; echo exit status $?; ls -l bbcbasic.html > Unknown reader: man > exit status 1 > /bin/ls: cannot access 'bbcbasic.html': No such file or directory > > Please reconsider the severity change. You originally reported an issue of "$ in nroff table causes spurious TeX-related failure". John pointed out (among other things) that (at least never releases) supports telling pandoc explicitly to parse as man page. I have trouble understanding what you are saying above: Do you argue that when explicitly telling pandoc to use man, you get the issue that you originally reported? Seems to me you have a different issue on being unable to parse as man. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#959851: pandoc: $ in nroff table causes spurious TeX-related failure
Control: severity -1 minor Control: retitle -1 pandoc: no warning fallback-parsing as markdown (expected fixed since v2.8) Quoting John MacFarlane (2020-05-06 20:06:30) > > Thank you for your report. If you'd run a more recent version of > pandoc, you'd have seen the additional warning: > > [WARNING] Could not deduce format from file extension .man > Defaulting to markdown > > which should explain things. > > Add '-f man' to your command line and it should work fine. (At > least it does with the most recent version.) Thanks, James, for reporting this. Thanks John, for providing valuable insight to correlating this with upstream code. Seems the helpful warning was added at git commit 680d7b5 and included since upstream release 2.8. Lowered this bugreport to minor and changed its subject, by the assumption that it works also in older versions when explicitly told which format to process, and the issue therefore is one of suboptimal feedback (in older releases, which we are kinda stuck with on Debian, due to the pain of Haskell needing to be upgraded all at once and the lack of volunteers helping with maintenance of Haskell packages). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#944978: pandoc: fails to convert horizontal rules from markdown to PDF (through LaTeX)
Quoting Francesco Poli (2019-11-18 22:40:11)
> On Mon, 18 Nov 2019 19:09:24 +0100 Jonas Smedegaard wrote:
>
> > Quoting John MacFarlane (2019-11-18 18:17:36)
> > >
> > > This is a known issue:
> > > https://github.com/jgm/pandoc/issues/5801
> > > It will be fixed in the upcoming pandoc 2.8 release.
> > >
> > > A simple workaround which could be backported
> > > would be to add this line to the default latex
> > > template (default.latex):
> > >
> > > \renewcommand{\linethickness}{0.05em}
> >
> > Thanks for the bugreport, Francesco, and for the quick reply, John.
> >
> > In fact, upstream bugfix require only unfuzzing to apply to the older
> > Debian release of Pandoc. Compiling now...
>
> Wow, this is one of the heartening stories that can reconcile me with
> Debian and Free Software!
> It's really good to see a bug reported, patched, and ready to be fixed
> in Debian unstable in about 67.2 ks ...
>
> Thanks a lot to you both, Jonas and John.
> Looking forward to seeing the upload to sid.
Unfortunately last part of entering unstable might be unusally slow:
Recently I forgot to extend the expiry of my PGP key until too late, so
recent uploads are held in incoming queue until the Debian keyring is
next updated (typically happpens about once a month late in the month).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#944978: pandoc: fails to convert horizontal rules from markdown to PDF (through LaTeX)
Quoting John MacFarlane (2019-11-18 18:17:36)
>
> This is a known issue:
> https://github.com/jgm/pandoc/issues/5801
> It will be fixed in the upcoming pandoc 2.8 release.
>
> A simple workaround which could be backported
> would be to add this line to the default latex
> template (default.latex):
>
> \renewcommand{\linethickness}{0.05em}
Thanks for the bugreport, Francesco, and for the quick reply, John.
In fact, upstream bugfix require only unfuzzing to apply to the older
Debian release of Pandoc. Compiling now...
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#922418: pandoc: Please reference texlive-latex-base package in the "install pdflatex" error message
Quoting Jonas Smedegaard (2019-02-15 18:19:45) > Quoting Chris Lamb (2019-02-15 18:10:13) > > % pandoc -o output.pdf input.md > > pdflatex not found. Please select a different --pdf-engine or install > > pdflatex > > > > I think this could be improved user-interface wise as pdflatex is > > in the "texlive-latex-base" package (and not a hypothetical "pdflatex" > > package). > > > > A patch is attached that turns this into: > > > > % pandoc -o output.pdf input.md > > pdflatex not found. Please select a different --pdf-engine or install > > pdflatex from the texlive-latex-base package > > Great! > > I'll expand that to the other clues now listed only in long description. Looking closer, this cannot easily be solved so elegantly, because same error message is used for a range of pdf programs in different Debian packages. What I will do instead to to mirror into README.Debian the hints already in long desription about which features need which suggested packages, and apply a modified patch to reference README.Debian. Thanks again for the bugreport, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#927689: pandoc: Package newer version available upstream
Quoting Clint Adams (2019-09-01 00:28:02) > On Sun, Apr 21, 2019 at 12:37:47PM +0200, Jonas Smedegaard wrote: > > As soon as those libraries gets updated - which will happen at some > > point _after_ Buster gets released - Pandoc will get updated too. > > It should be safe now (or when the mirrors update) to upload pandoc > 2.5. Great! Building now... If someone has spare time to package libraries, then the only thing blocking from upgrading to Pandoc 2.6 is ipynb 0.1 or newer: https://hackage.haskell.org/package/ipynb ...and newest release, Pandoc 2.7.3 additionally needs skylighting 0.8.1 or newer, cmark-gfm 0.3 or newer, and hslua-module-system 0.2 or newer: https://hackage.haskell.org/package/hslua-module-system - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: On our package plan
Quoting Dmitry Bogatov (2019-05-09 09:35:13) > We have pandoc[1], haskell-intern, haskell-swish that are maintained > separately from DHG_packages, we have cborg-json, which don't even > have Vcs-Git field, probably more packages in unexpected places. My > point is that we need more unification. > > [1] Jonas, I remember that you dislike team mainenance, but let me > try to convince you. For the record I don't "dislike team maintenance" but a) like each code project tracked separately (i.e. a "pandoc" git not "all-haskell" git) and b) don't understand the meta machinery and would prefer to not need to learn it (i.e. that others in the team deal with that). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#927689: pandoc: Package newer version available upstream
Priviet Andrew, Quoting Andrew Savchenko (2019-04-21 11:38:50) > <- What led up to the situation? > -> Unavailability of the newer Pandoc version in Debian repository > > <- What exactly did you do (or not do) that was effective (or ineffective)? > -> Searched stable and backports for the newer (2.7.X) version > > <- What was the outcome of this action? > -> No suitable version found > > <- What outcome did you expect instead? > -> Find newer version(s) readily available at upstream Thanks for your bugreport! Pandoc targeted Buster (the next stable Debian release) is updated as much as possible with the dependent libraries available. As soon as those libraries gets updated - which will happen at some point _after_ Buster gets released - Pandoc will get updated too. It is unlikely that a newer pandoc will get backported to stable, due to the complexity of backporting Haskell libraries. It might be possible to install pandoc from Debian testing onto a Debian stable system, however - at your own risk, obviously (personally I wouldn't mix and also do not use backports.debian.org). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#922418: pandoc: Please reference texlive-latex-base package in the "install pdflatex" error message
Quoting Chris Lamb (2019-02-15 18:10:13) > % pandoc -o output.pdf input.md > pdflatex not found. Please select a different --pdf-engine or install > pdflatex > > I think this could be improved user-interface wise as pdflatex is > in the "texlive-latex-base" package (and not a hypothetical "pdflatex" > package). > > A patch is attached that turns this into: > > % pandoc -o output.pdf input.md > pdflatex not found. Please select a different --pdf-engine or install > pdflatex from the texlive-latex-base package Great! I'll expand that to the other clues now listed only in long description. Thanks a lot! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: limited access rights
Quoting Ilias Tsitsimpis (2018-11-26 12:03:34) > On Mon, Nov 26, 2018 at 10:48AM, Jonas Smedegaard wrote: > > Apparently this team distrusts some of its members to manage Salsa - > > including me. [...] > We may missed some important restrictions to the "Maintainer" role, > but please do not assume the above scheme was chosen in bad faith. I do believe the distrust is in good faith. > > Someone in power please fix access rights for pandoc-sidenote. > > I see that both haskell-monad-gen, and pandoc-sidenote projects are > "Private" as opposed to the rest of our projects which are "Public". I > now also realize that switching a project's visibility level is not > allowed to "Maintainers". I changed both to "Public". Thanks. > > Or better: Let's grant everyone in the team equal powers, so that > > each of us can fix such issues ourselves, without bothering and > > waiting for others to nurse us. > > I am OK with revisiting the current permissions scheme, and granting > every DD of our group the "Owner" role. Do we know of any other team > doing that? I consider it an antipattern to distrust on Salsa package maintainers who already effectively is granted root access on millions of Debian systems globally. No matter how common a pattern stil an antipattern. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
limited access rights
Hi, Apparently this team distrusts some of its members to manage Salsa - including me. Someone in power please fix access rights for pandoc-sidenote. Or better: Let's grant everyone in the team equal powers, so that each of us can fix such issues ourselves, without bothering and waiting for others to nurse us. Please do not just grant more powers to me specifically: I don't want to have powers over others in this team, thank you. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Jonas Smedegaard (2018-11-18 15:57:35) > Quoting Jonas Smedegaard (2018-10-02 08:36:19) > > Recent releases of Pandoc need hsYaml. > > > > Would be nice if someone in the team could package that. > > I now package HsYAML myself (see bug#914000). If someone in the team > feel that package is better handled as part of the big set maintained > syncronously, then feel free to take over its maintenance. > > Upgrading Pandoc need these additional two changes: > > * haddock-library >= 1.6 > * hslua >= 1.0.1 > > I have tried to work around above requirements but it is beyond my > skills. Please if possible update those two libraries. HsYAML was now accepted into unstable. Anyone feel like updating haddock-library and hslua? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
Quoting Jonas Smedegaard (2018-10-02 08:36:19) > Recent releases of Pandoc need hsYaml. > > Would be nice if someone in the team could package that. I now package HsYAML myself (see bug#914000). If someone in the team feel that package is better handled as part of the big set maintained syncronously, then feel free to take over its maintenance. Upgrading Pandoc need these additional two changes: * haddock-library >= 1.6 * hslua >= 1.0.1 I have tried to work around above requirements but it is beyond my skills. Please if possible update those two libraries. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#914000: ITP: haskell-hsyaml -- Haskell YAML 1.2 parser
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: haskell-hsyaml Version : 0.1.1.2 Upstream Author : Herbert Valerio Riedel * URL : https://github.com/haskell-hvr/HsYAML * License : GPL-2+ Programming Lang: Haskell Description : Haskell YAML 1.2 parser HsYAML is a YAML 1.2 parser implementation for Haskell. . Features of @HsYAML@ include: . * Pure Haskell implementation with small dependency footprint and emphasis on strict compliance with the YAML 1.2 specification. * Direct decoding to native Haskell types via (aeson-inspired) typeclass-based API. * Support for constructing custom YAML node graph representation (including support for cyclic YAML data structures). * Support for the standard (untyped) Failsafe, (strict) JSON, and (flexible) Core "schemas" providing implicit typing rules as defined in the YAML 1.2 specification (including support for user-defined custom schemas). * Event-based API resembling LibYAML's Event-based API. * Low-level API access to lexical token-based scanner. This package is needed for recent releases of Pandoc. The package will be maintained in the Haskell team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvxR3wACgkQLHwxRsGg ASEa+Q//Ty9aPgwOw7lYYijF4kqw9p0qqEOyPjbSgPkXyxmdZQdg/coC/+Nv+t/z GYlVxtWWF8Ko7lZFUP7Yt2aQHkIAS0KT/mbNAelh1r2xM4lu5wr74Ex+5UbbIhBO QVMKTJ1P9ogEPtxyk8iGif+Lr7jKrqvfb8UXfaEqKtEsjWoXoz5/nmPo6PbK9Ybp 7mtl3yRnOmIQwUdU9MVoMsV4hcYjGa8qGcT5hnqdkhUMR8jBJE0K18wOyzjtAYVj NQlJx3f75gXjcjsRrAv/iOwBNqqU+Dw6DFsjf1nFwNz1v9JBiGf5/jNqxHx0xQvT NwEYdqajM/6cpU5VSu9E7gBNlez+3O8ocrzqwgkkXwKMRgaxj1bWGRZMmn7BQMec SgyDtyVsiGvzzh3IzV+6MBQRJEPJdzOycaKCldnXZiKgqhUlMSW8pg9KmuKnH3t7 mmj5WKOXsP0KSMKladmtfqwf1FtovK/JsqShI5LZBZ57wKPU94/C9eYFzvSehleJ ADSLWymHN+OQtEkzVY0YYx3gwodVntxwwZGM6jQIEZuBSY9Qfa+PcxAfcNt0YnYa HUUfXdVf0S5Swk5ms65Hs6JDRR4oeS6xZo8NM8byeRU1Ko6H7dI+N3nFdtfH9S2F lGxcJmyeGJMtHgJ+SX1VCnRRhXprgBciUwFadCoLNHnFFCTJ0ow= =WkPo -END PGP SIGNATURE-
Bug#913960: ITP: haskell-monad-gen -- simple monad for generating fresh integers
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: haskell-monad-gen Version : 0.3.0.1 Upstream Author : Danny Gratzer * URL : https://bitbucket.org/jozefg/monad-gen * License : Expat Programming Lang: Haskell Description : simple monad for generating fresh integers This Haskell module provides a simple monad transformer @GenT@ to enumerate unique values within a monadic computation. It also plays nicely with everything in the MTL. This package is needed for upcoming package pandoc-sidenote Packaging will be maintained in the Haskell team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvwGRYACgkQLHwxRsGg ASFaXg/8C3EpnZnheQQqFTkyV1hhWjcHUR/fddcj6jZmOhwoyQ0v0K5AekjMO26r js1D8acWdpQUCA4fz59poxmf278Nrjvjmmuzy68BJF99Zlsvy26fdoxUUG7cXl2x g5Km5lLoIHM3e3WnU1IRD0bkVOp293Pcdur7JjQcj8bi1SDAyJkcfnOjb3ONQGuT wTWo7hHxFDSNl+BFv1Iu+mTod4ao0UhQibzf7OMECLPNL88Oa6rErJs2QO0QEGx7 0jcS6ZUIz7D7GXvtiCl9+XNQhwGFB42meavpM4Aslm67SH98ZY2LKXPKQ6IhVzH/ dfqKBnEIeolVKF7ReiJHIcDsD/X7W2nOrfmBcCB3xFzz9xVpdogznne2KJ6rN5zj BUkXD/PgcEO+Q6ihxCVTAqWt48lQJdniIjvAgbyTaRWmCRFN8Zq+mLHI5M1rfj17 R5ECz+020mdvmIj4s34rzfnFFAONGgnrOLQiML4sFchP0amvYgf6PYEWhHy8Xv3E d2iqfPIBmcQjegFyZQVRlG7G0U71C/b6r6eCM0ZzMf2ePuTYaZ4/+vQ2Bbamf85G Es/tG/YUWEYG/QE6SGoBIVqC+KimUrdYO8g/n6E5dSBE6L92A4xqkzD2AgvQalIW NvItPp1y8qz9zgZFoYHVyFW9RSUIsFzrgFDd0ERNUE53p/7gVjc= =V+IB -END PGP SIGNATURE-
Re: new upcoming Pandoc dependency
Hi Ilias, Quoting Ilias Tsitsimpis (2018-10-23 16:20:14) > On Thu, Oct 18, 2018 at 08:23AM, Jonas Smedegaard wrote: > > Why do you try upgrade to Pandoc 2.3.1 when that is not supported by > > BlogLiterally? > > From what you said, I understood that you had pandoc-2.3.1 ready to be > uploaded, so I tested it against the current set of Haskell packages > to see whether it was compatible or not. I couldn't know that until I > had tested it. Ah, I understand. My choice of word was bad: I meant it was ready for _after_ the current set of Haskell libraries had entered unstable. I am still quite interested in the possibility of getting hsYaml packaged, so that I can try explore if possible to relax some of the other library dependencies too tight for what is now entering unstable. > > I would guess that the solution is to simply request a binNMU of > > Pandoc - not touch its source at all for that migration. > > I agree with you. We should stay with pandoc-2.2.1 for the time being. > > It seems that binNMUs will not work, since pandoc build-depends on > libghc-tasty-dev (< 1.1), but 1.1.0.3 is available on unstable. Could > you please fix that? Great. I am on it now! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: new upcoming Pandoc dependency
I Ilias, Quoting Ilias Tsitsimpis (2018-10-16 11:26:57) > On Tue, Oct 02, 2018 at 08:36AM, Jonas Smedegaard wrote: > > Recent releases of Pandoc need hsYaml. > > > > Would be nice if someone in the team could package that. > > > > NB! I have a newer pandoc package prepared locally, for when the > > current upgrade of Haskell libraries enter unstable. So please do > > *not* upload a sourceful release of Pandoc without coordinating with > > me. > We currently track LTS 12.10 which still has pandoc 2.2.1. I tried to > upgrade pandoc to 2.3.1 in our package-plan and it failed with: > > trying: BlogLiterately-0.8.6.2 (user goal) > next goal: pandoc (user goal) > rejecting: pandoc-2.3.1 (conflict: BlogLiterately => pandoc>=2.0 && > <2.3) > > Is this something that we would be able to fix on our own, or should > we stay with pandoc 2.2.1 for the time being (until it is updated on > Stackage)? I don't understand in what way I can be helpful to above issue. Why do you try upgrade to Pandoc 2.3.1 when that is not supported by BlogLiterally? I would guess that the solution is to simply request a binNMU of Pandoc - not touch its source at all for that migration. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Haskell ghc-8.4 migration
Hi Dmitry, Quoting Dmitry Bogatov (2018-10-18 00:00:21) > Right now I try to move ghc-8.4 migration forward, and xmonad does not > build, since it depends on libghc-pandoc-dev. > > I remember, Jonas, you asked to not touch pandoc without coordination > with you, so how would we proceed? Thanks for involving me! In what ways do current Pandoc block migration of ghc? If a binNMU is not suitable, then is it possible to release the build-dependencies of Pandoc? If that was done already, then I simply missed that (and would appreciate a notification next time, or a pointer what I should watch out for). > And, by the way, why pandoc is not in DHG_packages? Thanks for asking :-) I understand how to maintain single packages but not how to "steer the fleet" of (re)building all Haskell packages at once - and don't have the computing power to do so either. Also, I like being able to maintain single packages: Feels more inclusive to me. I have similar concerns for the Rust team, who did a similar approach - the approach taken by the Perl team is more to my liking. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#910280: pandoc: Please reduce the binary size
Quoting kact...@gnu.org (2018-10-05 02:28:17) > > [2018-10-05 00:50] Jonas Smedegaard > > Quoting John MacFarlane (2018-10-04 19:58:54) > > > Jonas Smedegaard writes: > > > > > > > The proper solution here, I guess (but am not expert in Haskell > > > > so may be wrong) is to switch to using shared linking, so that 5 > > > > Haskell binaries will not consume 5 x the disk space of the > > > > parts reused among them. > > We could generate packages with compressed binaries in a way, similar > to *-dbg packages. All compiled languages, except C (Go, Rust, > Haskell) would benefit, but it is quite a bit of work -- changes to > debhelper and reprorepo, at least. We could, yes. Personally I will not drive that effort, however. I encourage you to consider driving it yourself, KAction. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#910280: pandoc: Please reduce the binary size
Control: tag -1 wontfix Hi Горбешко, Quoting Горбешко Богдан (2018-10-04 13:02:59) > the pandoc binary is extremely large. It's the largest file in my > /usr/bin, exceeding even blender's binary in almost 2 times. > > From my experience, ghc is not good at making small binaries, and > even stripping doesn't do much. However UPX does it's job great on > binaries produced by ghc. I tried compressing pandoc in --best mode > and achieved 14% compression (from 141M to 20M); however the > compression took more than an hour on my system. > > If you are afraid of performance decreasing that may arise because of > UPXing, you can make pandoc a virtual package, pointing by default to > a non-compressed real package, but providing a compressed real package > as well, for those who care about disk space. I agree that the binary is big, but I disagree with shipping a compressed binary - even as an alternative only. Reason Pandoc is big is that it is statically linked. If statically linked with FFmpeg, Boost, Cairo, Mesa, GDAL, GTK+, HDF4, HDF5, Lapack, etc., Blender would be much much larger than Pandoc. Providing a compressed binary will just shift the burden elsewhere, and providing as alternative shifts the burden to the distribution mirrors. The proper solution here, I guess (but am not expert in Haskell so may be wrong) is to switch to using shared linking, so that 5 Haskell binaries will not consume 5 x the disk space of the parts reused among them. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
new upcoming Pandoc dependency
Hi, Recent releases of Pandoc need hsYaml. Would be nice if someone in the team could package that. NB! I have a newer pandoc package prepared locally, for when the current upgrade of Haskell libraries enter unstable. So please do *not* upload a sourceful release of Pandoc without coordinating with me. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#888468: pandoc: please support new YAML fields "front/back-notice" for LaTeX and HTML5 output
Quoting Francesco Poli (2018-06-17 19:50:22) > On Fri, 01 Jun 2018 12:28:45 -0700 John MacFarlane wrote: >> If you care about the feature, you may propose it upstream on the >> pandoc-discuss mailing list or the jgm/pandoc issue tracker on >> GitHub. That is the way it will be most convenient for upstream >> developers to consider it. > > I created that little patch and I sent it to the Debian package > maintainers, since I thought it could be useful for other people. > > But I am currently not intending to get more heavily involved in pandoc > upstream development. > And I cannot register an account or subscribe to a mailing list for > each and every upstream project I intend to make a little contribution > to. Sorry about that. > > I am open to constructive criticism about my patch (via e-mail, > please), if you, as pandoc upstream developer(s), are interested in > taking a look at it and, possibly, in adopting (a refined version of) > it. > But I do not have the time to jump through bureaucratic hoops, in > order to have the patch accepted upstream... Perfectly understandable. I will leave this bugreport open for a while, to see if John or others decide to drive your proposal further. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
