Re: Samba FTBFS - no idea why
On 04/12/15 12:45, Mark Cave-Ayland wrote:
> 'configure' finished successfully (13m9.177s)
> A local copy of the docbook.xsl wasn't found on your system consider
> installing package like docbook-xsl
> A local copy of the docbook.xsl wasn't found on your system consider
> installing package like docbook-xsl
> A local copy of the docbook.xsl wasn't found on your system consider
> installing package like docbook-xsl
>
> It looks like the build script is installing the docbook-xsl package
> into the chroot but configure isn't finding the stylesheets for the bad
> build which explains the behaviour you see. I do remember having to
> patch stylesheet paths in configure for some packages a while back but
> that was a couple of years ago... I'd go back and check whether the
> stylesheet parts of docbook-xsl have been split into a separate package
> which requires a new dependency or whether the paths to the stylesheets
> in the package themselves are different between the two builds and
> whether they match those in Samba's configure script.
I've just checked the Samba 4.1 repository at git.samba.org and they
have this in samba_conftests.py to find the docbook stylesheet:
s='http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl'
conf.CHECK_COMMAND('%s --nonet %s 2> /dev/null' %
(conf.env.XSLTPROC, s),
msg='Checking for stylesheet %s' % s,
define='XSLTPROC_MANPAGES', on_target=False,
boolean=True)
or just:
xsltproc
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
--nonet
While the download fall-back should work, my personal experience has
been that the docbook.xsl download is terribly flakey, presumably since
as the default behaviour is to download any missing .xsl files on every
invocation then the origin servers must struggle with load at peak times.
This does however point the finger more towards the docbook-xsl rather
than the Samba package though.
ATB,
Mark.
Reply to: