Thread
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Normalize whitespace in the arguments of <indexterm>
- 9412606265c2 9.1.0 cited
-
make world fails
Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-04-27T19:39:01Z
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 -
Re: make world fails
Tom Lane <tgl@sss.pgh.pa.us> — 2011-04-27T20:14:00Z
"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
-
Re: make world fails
Alvaro Herrera <alvherre@commandprompt.com> — 2011-04-27T20:28:32Z
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
-
Re: make world fails
Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-04-27T20:29:19Z
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
-
Re: make world fails
Dave Page <dpage@pgadmin.org> — 2011-04-27T20:35:38Z
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
-
Re: make world fails
Alvaro Herrera <alvherre@commandprompt.com> — 2011-04-27T20:54:57Z
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
-
Re: make world fails
Peter Eisentraut <peter_e@gmx.net> — 2011-04-27T21:57:28Z
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
-
Re: make world fails
Tom Lane <tgl@sss.pgh.pa.us> — 2011-04-28T04:03:16Z
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
-
Re: make world fails
Peter Eisentraut <peter_e@gmx.net> — 2011-05-01T10:26:21Z
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.