Bug#964208: wsjtx: FTBFS without internet access
On Sun, Jul 05, 2020 at 09:55:30PM +0200, Christoph Berg wrote: > Re: tmanc...@debian.org > > > I/O error : Attempt to load network entity > > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > > warning: failed to load external entity > > > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; > > > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 > > > element import > > > xsl:import : unable to load > > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > > ... > > > > So I propose that we reassign this to asciidoc, since any package that > > build-depends on asciidoc and uses the manpage stylesheet should fail in > > the same manner. I don't have any experience with XSL stylesheets, but > > I assume that the asciidoc package can be updated to include the > > necessary components such that xsl files need not be fetched from the > > network during the build. > > > > Does that sound reasonable to folks? > > The primary problem is that we are missing a build-dependency on > docbook-xsl and possibly more packages of the xsl family which contain > the necessary files. > > I can't say if that is actually a bug in asciidoc to not depend on > the bunch. (I guess at least a Recommends or Suggests there is in > order, but that wouldn't fix the B-D problem.) Ooh, thank you for the tip about docbook-xsl! That gives us a path forward for wsjtx. I see what you're saying about this maybe not being a bug for asciidoc. For now I'll add docbook-xsl to the B-D for wsjtx and upload with the patch for XSLTPROC_OPTS to add --nonet. Thanks, tony
Bug#964208: wsjtx: FTBFS without internet access
Re: tmanc...@debian.org > For now I'll add docbook-xsl to the B-D for wsjtx > and upload with the patch for XSLTPROC_OPTS to add --nonet. That's the best option, I think. Thanks! Christoph
Bug#964208: wsjtx: FTBFS without internet access
Re: tmanc...@debian.org > > I/O error : Attempt to load network entity > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > warning: failed to load external entity > > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; > > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 > > element import > > xsl:import : unable to load > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > ... > > So I propose that we reassign this to asciidoc, since any package that > build-depends on asciidoc and uses the manpage stylesheet should fail in > the same manner. I don't have any experience with XSL stylesheets, but > I assume that the asciidoc package can be updated to include the > necessary components such that xsl files need not be fetched from the > network during the build. > > Does that sound reasonable to folks? The primary problem is that we are missing a build-dependency on docbook-xsl and possibly more packages of the xsl family which contain the necessary files. I can't say if that is actually a bug in asciidoc to not depend on the bunch. (I guess at least a Recommends or Suggests there is in order, but that wouldn't fix the B-D problem.) Christoph
Bug#964208: wsjtx: FTBFS without internet access
On Sat, Jul 04, 2020 at 01:08:32PM +0200, Christoph Berg wrote: > Ideally we should add some --nonet flag to make the failure both more obvious > and reproducible. Here's an update on this bug... There is a "--nonet" option that can be passed to xsltproc, but the build fails when that option is used, returning error code 5; from the xsltproc manpage: 5 Error in the stylesheet The issue lies in the asciidoc package when the manpage stylesheet is used in conjunction with --nonet. I tweaked the autopkgtest to show the failure and pushed a branch and created a merge request [1]. From the verbose output of the now failing test: > ... > creating dictionary for stylesheet > reusing dictionary from /etc/asciidoc/docbook-xsl/manpage.xsl for stylesheet > xsltParseStylesheetProcess : found stylesheet > xsltPreprocessStylesheet: removing ignorable blank node > Reusing dictionary for document > I/O error : Attempt to load network entity > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 element > import > xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > ... So I propose that we reassign this to asciidoc, since any package that build-depends on asciidoc and uses the manpage stylesheet should fail in the same manner. I don't have any experience with XSL stylesheets, but I assume that the asciidoc package can be updated to include the necessary components such that xsl files need not be fetched from the network during the build. Does that sound reasonable to folks? Thanks, tony [1] https://salsa.debian.org/debian/asciidoc/-/merge_requests/1 signature.asc Description: PGP signature
Bug#964208: wsjtx: FTBFS without internet access
Ideally we should add some --nonet flag to make the failure both more obvious and reproducible.
Bug#964208: wsjtx: FTBFS without internet access
Hi Niko, On Fri, Jul 03, 2020 at 07:47:21PM +0300, Niko Tyni wrote: > Source: wsjtx > Version: 2.2.1+repack-1 > Severity: serious > Tags: ftbfs > > This package fails to build on a system without internet access. > I suppose it's xsltproc calling out for external resources or something > like that. > > This is probably the cause for the 2.2.2+repack-1 armhf build failure too; > I think the conova buildds only have IPv6 connectivity. Thank you for connecting the dots... I reproduced this exact build failure on amd64 by disabling the network. > From the build log: > > a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param > man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics > 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" > "/<>/obj-x86_64-linux-gnu/manpages/man/man1/wsjtx.1.xml" > returned non-zero exit status 5 Cheers, tony signature.asc Description: PGP signature
Bug#964208: wsjtx: FTBFS without internet access
Source: wsjtx Version: 2.2.1+repack-1 Severity: serious Tags: ftbfs This package fails to build on a system without internet access. I suppose it's xsltproc calling out for external resources or something like that. This is probably the cause for the 2.2.2+repack-1 armhf build failure too; I think the conova buildds only have IPv6 connectivity. >From the build log: make[3]: Entering directory '/<>/obj-x86_64-linux-gnu' cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /<> /<> /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu /<>/obj-x86_64-linux-gnu/CMakeFiles/wsjt_fort_autogen.dir/DependInfo.cmake --color= a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/<>/obj-x86_64-linux-gnu/manpages/man/man1/wsjtx.1.xml" returned non-zero exit status 5 make[3]: *** [manpages/CMakeFiles/manpages.dir/build.make:73: manpages/man/man1/wsjtx.1.gz] Error 1 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:2390: manpages/CMakeFiles/manpages.dir/all] Error 2 -- Niko Tyni nt...@debian.org
