Re: make world fails

I just did my usual:

make maintainer-clean \
&& ./configure --prefix=/usr/local/pgsql-serializable \
--enable-debug \
--enable-cassert \
--enable-depend \
--with-libxml \
--with-python \
&& make world

Which ended badly with the attached.

I've been running this pretty much every day on one or two machines,
and this is new.

-Kevin

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I just did my usual:
> make maintainer-clean \
> && ./configure --prefix=/usr/local/pgsql-serializable \
> --enable-debug \
> --enable-cassert \
> --enable-depend \
> --with-libxml \
> --with-python \
> && make world

> Which ended badly with the attached.

Hmm, does it work any better if you revert
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9412606265c2774712e3f805798896734b32c7fd
?

regards, tom lane

Excerpts from Kevin Grittner's message of mié abr 27 16:39:01 -0300 2011:
> I just did my usual:
>
> make maintainer-clean \
> && ./configure --prefix=/usr/local/pgsql-serializable \
> --enable-debug \
> --enable-cassert \
> --enable-depend \
> --with-libxml \
> --with-python \
> && make world
>
> Which ended badly with the attached.
>

> xsltproc --stringparam pg.version '9.1devel' stylesheet-man.xsl postgres.xml
> error : No such file or directory
> warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
> compilation error: file stylesheet-man.xsl line 7 element import
> xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

I think somebody mentioned long ago that the new manpage-generating
toolchain can sometimes attempt to download XSL documents from that
website, if not present in the machine. When you have a working
connection and the site is up it works fine, but bombs out as soon as
there's a network glitch etc.

I think you need to install some Docbook XSL package or other.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> I just did my usual:
>> make maintainer-clean \
>> && ./configure --prefix=/usr/local/pgsql-serializable \
>> --enable-debug \
>> --enable-cassert \
>> --enable-depend \
>> --with-libxml \
>> --with-python \
>> && make world
>
>> Which ended badly with the attached.
>
> Hmm, does it work any better if you revert
>
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9412606265c2774712e3f805798896734b32c7fd
> ?

It worked with that reverted. I went back to the master branch and
it worked there, too, on a retry. Could a transient failure to
communicate with the referenced URL on the Internet:

http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

have caused this failure? I don't know for sure that there was a
failure, but that's what the message seemed to say. I *can* access
that page with my browser at the moment.

Is the build contingent on Internet access? Should it be?

-Kevin

On Wed, Apr 27, 2011 at 9:29 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>>> I just did my usual:
>>> make maintainer-clean \
>>>  && ./configure --prefix=/usr/local/pgsql-serializable \
>>>                 --enable-debug \
>>>                 --enable-cassert \
>>>                 --enable-depend \
>>>                 --with-libxml \
>>>                 --with-python \
>>>  && make world
>>
>>> Which ended badly with the attached.
>>
>> Hmm, does it work any better if you revert
>>
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9412606265c2774712e3f805798896734b32c7fd
>> ?
>
> It worked with that reverted.  I went back to the master branch and
> it worked there, too, on a retry.  Could a transient failure to
> communicate with the referenced URL on the Internet:
>
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
>
> have caused this failure?  I don't know for sure that there was a
> failure, but that's what the message seemed to say.  I *can* access
> that page with my browser at the moment.
>
> Is the build contingent on Internet access?  Should it be?

I periodically see the installer builds fail at this step. It's really annoying.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Excerpts from Alvaro Herrera's message of mié abr 27 17:28:32 -0300 2011:

> I think you need to install some Docbook XSL package or other.

In my system (Debian) I have a catalog.xml file from the docbook-xsl
package which has these two lines in it:

<rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="./"/>
<rewriteSystem systemIdStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="./"/>

(where the ./ appears to refer to the
/usr/share/xml/docbook/stylesheet/docbook-xsl directory)

I take it that if I have a manpages/docbook.xsl in that path, it uses
that instead of trying to fetch it from sourceforge.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On ons, 2011-04-27 at 17:54 -0300, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of mié abr 27 17:28:32 -0300 2011:
>
> > I think you need to install some Docbook XSL package or other.
>
> In my system (Debian) I have a catalog.xml file from the docbook-xsl
> package which has these two lines in it:
>
> <rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="./"/>
> <rewriteSystem systemIdStartString="http://docbook.sourceforge.net/release/xsl/current/" rewritePrefix="./"/>
>
> (where the ./ appears to refer to the
> /usr/share/xml/docbook/stylesheet/docbook-xsl directory)
>
> I take it that if I have a manpages/docbook.xsl in that path, it uses
> that instead of trying to fetch it from sourceforge.

Exactly.

If you don't want to depend on net access, you can do something like

make whatever XSLTPROCFLAGS=--nonet

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On ons, 2011-04-27 at 17:54 -0300, Alvaro Herrera wrote:
>> I take it that if I have a manpages/docbook.xsl in that path, it uses
>> that instead of trying to fetch it from sourceforge.

> Exactly.

> If you don't want to depend on net access, you can do something like
> make whatever XSLTPROCFLAGS=--nonet

Is there a way to say "fetch all the documents I need for this build
into my local cache"? Then you could do that when your network was up,
and not have to worry about failures in future. The set of URIs we
reference doesn't change much.

regards, tom lane

On tor, 2011-04-28 at 00:03 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On ons, 2011-04-27 at 17:54 -0300, Alvaro Herrera wrote:
> >> I take it that if I have a manpages/docbook.xsl in that path, it uses
> >> that instead of trying to fetch it from sourceforge.
>
> > Exactly.
>
> > If you don't want to depend on net access, you can do something like
> > make whatever XSLTPROCFLAGS=--nonet
>
> Is there a way to say "fetch all the documents I need for this build
> into my local cache"? Then you could do that when your network was up,
> and not have to worry about failures in future. The set of URIs we
> reference doesn't change much.

No, not without some external program to do the caching.