On Tue, Feb 02, 2021 at 04:25:36PM +0100, Arturo Borrero Gonzalez wrote: > I suspect this might be related to this recent change: > > https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4eb323698ee7d8e50132fb271c0f3aa92c727285 > > Could you please check if introducing back docbook-xsl as build-dep fixes the > issue?
Mea culpa. My analysis concluded that since there are no docbook files in the source and there are no xsltproc invocations, that it would not use xsltproc. I did not anticipate that it would use xsltproc via a2x from asciidoc. Much less that the usage would be architecture dependent. I actually verified that my change would not result in changed output artifacts (as in reproducible), but I only performed the testing on amd64. So this is how I missed it. I'll pay more attention when running into asciidoc in future. I do wonder though whether this really is a bug in nftables. Should nftables really be concerned with how asciidoc operates? If I have an asciidoc file and want a manual page, how should I know that I need docbook-xsl in addition to asciidoc? asciidoc-base already depends on xsltproc. Maybe asciidoc-base should also quite simply depend on docbook-xsl? Of course, that would get us a bigger dependency tree than before. Quite the opposite of what I wanted to achieve. It would be one with fewer surprises though. What do you think? Adding the asciidoc maintainer to Cc. Helmut
