Обсуждение: 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.Grittner@wicourts.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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.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.Grittner@wicourts.gov> wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Kevin Grittner" <Kevin.Grittner@wicourts.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@commandprompt.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@gmx.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@gmx.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.