Bug#889017: Bug#888953: gobby accesses the network during the build
Control: severity -1 normal On Thu, Feb 01, 2018 at 10:38:08AM +, Simon McVittie wrote: > On Thu, 01 Feb 2018 at 11:23:28 +0200, Adrian Bunk wrote: > > On Wed, Jan 31, 2018 at 03:53:11PM +0100, Matthias Klose wrote: > > > While seen on a launchpad build, it looks like a missing build dependency, > > > because it tries to access the docbookx.dtd from the network: > > My understanding is that it's currently up to the package being built > (e.g. gobby, not gnome-doc-utils) to build-depend on the appropriate > package to get the DTDs of its XML documentation to be registered > in the xml-core catalog and available without hitting the network: > docbook-xml for docbookx.dtd, rarian-compat for scrollkeeper-omf.dtd, > and possibly others. >... For the same issue in yelp-tools (#839549), is this also a missing build dependency in aisleriot? > > There is also the related issue that > > /usr/share/gnome-doc-utils/gnome-doc-utils.make > > shouldn't call xmllint without --nonet > > I'm not sure that this would be a good idea to do > unconditionally. gnome-doc-utils.make gets copied into source packages > by gnome-doc-prepare (analogous to autoconf, automake, libtoolize) so > by making this change, we would be imposing Debian policy on upstream > packages that happen to have been prepared by a `make dist` on a Debian > system. > > In Debian, accessing the network during build is forbidden (for good > reason), and we have the xml-core catalog as a way to get DTDs without > doing so. However, when packages whose upstream release happens to have > been made on a Debian system are built on less enlightened distributions > that don't have (or want) that policy, and that don't necessarily even > have an equivalent of xml-core, they still need to build successfully. > > Is there a canonical way to detect that we are in a Debian package build, > that could be used to add --nonet to the xmllint command-line if and only > if this is a Debian package build? The yelp-tools fix of adding it only to "make check" might also apply here? https://git.gnome.org/browse/yelp-tools/commit/?id=71e8c4bd285a576ad3b3c38eb6aa9a2a0a1b24de > smcv cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#888953: gobby accesses the network during the build
On 02/01/2018 01:45 PM, Simon McVittie wrote: >> Well, I suppose it'd help if there would be some guidance on how to do >> things today. I'm (somewhat) happy to fix it upstream if needed. > Here's upstream's migration guide, with links to the commits used to > migrate an example package: > https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure > (I'll try to follow up to the other bugs from the same MBF as #885642 at > some point with a reference to this.) Ok, thanks. I did that and uploaded a new version. I hope that the new toolchain does not access the network. I have honestly no clue how I'd successfully test for that locally. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#888953: gobby accesses the network during the build
On Thu, 01 Feb 2018 at 12:40:16 +0100, Philipp Kern wrote: > I'll note that I was told to stop build-depending on rarian-compat in > #885642, which then introduced this bug. That request was less clear than it could have been, but the intention was to stop using the deprecated documentation toolchain, not just stop build-depending on parts of it. > > (For context, Scrollkeeper is very obsolete, rarian-compat is an > > obsolete > > compatibility shim for Scrollkeeper, and gnome-doc-utils has itself > > been superseded by yelp-tools; it's deprecations all the way down. > > Well, I suppose it'd help if there would be some guidance on how to do > things today. I'm (somewhat) happy to fix it upstream if needed. Here's upstream's migration guide, with links to the commits used to migrate an example package: https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure (I'll try to follow up to the other bugs from the same MBF as #885642 at some point with a reference to this.) smcv
Bug#888953: gobby accesses the network during the build
On 2018-02-01 11:38, Simon McVittie wrote: On Thu, 01 Feb 2018 at 11:23:28 +0200, Adrian Bunk wrote: On Wed, Jan 31, 2018 at 03:53:11PM +0100, Matthias Klose wrote: > While seen on a launchpad build, it looks like a missing build dependency, > because it tries to access the docbookx.dtd from the network: My understanding is that it's currently up to the package being built (e.g. gobby, not gnome-doc-utils) to build-depend on the appropriate package to get the DTDs of its XML documentation to be registered in the xml-core catalog and available without hitting the network: docbook-xml for docbookx.dtd, rarian-compat for scrollkeeper-omf.dtd, and possibly others. I'll note that I was told to stop build-depending on rarian-compat in #885642, which then introduced this bug. [...] (For context, Scrollkeeper is very obsolete, rarian-compat is an obsolete compatibility shim for Scrollkeeper, and gnome-doc-utils has itself been superseded by yelp-tools; it's deprecations all the way down. I've asked the ftp team to override gnome-doc-utils from gnome to oldlibs, and pushed a better package description to gnome-team git for inclusion in the next upload.) Well, I suppose it'd help if there would be some guidance on how to do things today. I'm (somewhat) happy to fix it upstream if needed. Kind regards and thanks Philipp Kern
Bug#888953: gobby accesses the network during the build
On Thu, 01 Feb 2018 at 11:23:28 +0200, Adrian Bunk wrote: > On Wed, Jan 31, 2018 at 03:53:11PM +0100, Matthias Klose wrote: > > While seen on a launchpad build, it looks like a missing build dependency, > > because it tries to access the docbookx.dtd from the network: My understanding is that it's currently up to the package being built (e.g. gobby, not gnome-doc-utils) to build-depend on the appropriate package to get the DTDs of its XML documentation to be registered in the xml-core catalog and available without hitting the network: docbook-xml for docbookx.dtd, rarian-compat for scrollkeeper-omf.dtd, and possibly others. If GNOME-2-style documentation always includes both Docbook and Scrollkeeper/Rarian OMF format (I'm not clear on the details) then perhaps gnome-doc-utils should have Depends on both of those. If they are not always needed, then it probably shouldn't. (For context, Scrollkeeper is very obsolete, rarian-compat is an obsolete compatibility shim for Scrollkeeper, and gnome-doc-utils has itself been superseded by yelp-tools; it's deprecations all the way down. I've asked the ftp team to override gnome-doc-utils from gnome to oldlibs, and pushed a better package description to gnome-team git for inclusion in the next upload.) > There is also the related issue that > /usr/share/gnome-doc-utils/gnome-doc-utils.make > shouldn't call xmllint without --nonet I'm not sure that this would be a good idea to do unconditionally. gnome-doc-utils.make gets copied into source packages by gnome-doc-prepare (analogous to autoconf, automake, libtoolize) so by making this change, we would be imposing Debian policy on upstream packages that happen to have been prepared by a `make dist` on a Debian system. In Debian, accessing the network during build is forbidden (for good reason), and we have the xml-core catalog as a way to get DTDs without doing so. However, when packages whose upstream release happens to have been made on a Debian system are built on less enlightened distributions that don't have (or want) that policy, and that don't necessarily even have an equivalent of xml-core, they still need to build successfully. Is there a canonical way to detect that we are in a Debian package build, that could be used to add --nonet to the xmllint command-line if and only if this is a Debian package build? smcv
Bug#888953: gobby accesses the network during the build
Control: clone -1 -2 Control: reassign -2 gnome-doc-utils Control: retitle -2 gnome-doc-utils.make should forbid accessing the network On Wed, Jan 31, 2018 at 03:53:11PM +0100, Matthias Klose wrote: > Package: src:gobby > Version: 0.6.0~20170204~e5c2d1-2 > Severity: serious > Tags: sid buster > > While seen on a launchpad build, it looks like a missing build dependency, > because it tries to access the docbookx.dtd from the network: > > make[3]: Leaving directory '/<>/po' > Making check in help > make[3]: Entering directory '/<>/help' > xmllint --noout --noent --path C:./C --xinclude --postvalid ./C/gobby.xml > xmllint --noout --xinclude --dtdvalid > 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' > gobby-C.omf >... There is also the related issue that /usr/share/gnome-doc-utils/gnome-doc-utils.make shouldn't call xmllint without --nonet, cloning a second bug for that. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#888953: gobby accesses the network during the build
Package: src:gobby Version: 0.6.0~20170204~e5c2d1-2 Severity: serious Tags: sid buster While seen on a launchpad build, it looks like a missing build dependency, because it tries to access the docbookx.dtd from the network: make[3]: Leaving directory '/<>/po' Making check in help make[3]: Entering directory '/<>/help' xmllint --noout --noent --path C:./C --xinclude --postvalid ./C/gobby.xml xmllint --noout --xinclude --dtdvalid 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' gobby-C.omf error : error : No such file or directory No such file or directory warning: failed to load external entity "http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd; Could not parse DTD http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd ./C/gobby.xml:6: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd; ]> ^ Makefile:945: recipe for target 'check-doc-omf' failed make[3]: *** [check-doc-omf] Error 2 make[3]: *** Waiting for unfinished jobs error : No such file or directory warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd; validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd; Document ./C/gobby.xml does not validate Makefile:917: recipe for target 'check-doc-docs' failed make[3]: *** [check-doc-docs] Error 3 make[3]: Leaving directory '/<>/help' Makefile:1272: recipe for target 'check-recursive' failed make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory '/<>' Makefile:1567: recipe for target 'check' failed make[1]: *** [check] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: make -j4 check VERBOSE=1 returned exit code 2 debian/rules:6: recipe for target 'build' failed make: *** [build] Error 2 https://launchpad.net/ubuntu/+source/gobby/0.6.0~20170204~e5c2d1-2/+build/14219811
