On Wed, Mar 28, 2012 at 04:18:02PM +0200, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 27.03.2012, 21:49 +0200 schrieb Iustin Pop: > > I looked at > > https://buildd.debian.org/status/package.php?p=pandoc&suite=sid&compact=compact > > and it shows pandoc as having the following build failures: > > > > - i386, sparc: pandoc-1.9.1.1-d52ba5f3dfa50033e02c4efb4fcaa204 is > > unusable due to missing or recursive dependencies: > > zip-archive-0.1.1.7-463904d956f1052cc58a2c9e5deeee2c > > strange, pandoc is built, there is only one zip-archive installed, so > why would it reference a different zip-archive hash? And why does it > fail during the haddock phase? I have not seen that before... > > I gave back the build, maybe it is temporary. On i386 and sparc it built fine already, thanks. > > - mips, s390: virtual memory exhausted: Cannot allocate memory > > - mipsel: E: Caught signal 'Terminated': terminating immediately > > - hurd-i386: hlibrary.setup: /usr/bin/ghc-pkg: interrupted > > > > I'm not familiar with the mips/s390 ports (do they really have so few > > virtual memory?), but at least the i386/sparc builds look like they > > should be retried, right? If so, is anyone familiar with requesting a > > retry? > > I scheduled a retry, but if virtual memory is the bound then it maybe > well be that we have to remove the packages on these arches; not even a > machine with more physical memory would help. At least s390 has only > half the virtual memory that i386 has and indeed this causes a few > packages to fail. I see. I didn't know that pandoc has such high build requirements. It failed again on s390, I would presume it'll fail on mips too. Since I need pandoc to go from markdown to man page, does this mean I would be better served with storing the built man page in the debian/ directory and VCS, and installing it directly (instead of building it from markdown at build time)? One less build dependency, but one more manual step. Hmmm… thanks, iustin
Attachment:
signature.asc
Description: Digital signature