Thread: Problem building 9.0 Beta 3 US PDF file
Hi,
I could build 9.0 Beta 3 A4 PDF without any issues, but I think something is broken in US PDF generation:
===============================================
$ time make -j3 postgres-US.pdf
{ \
echo "<!entity version \"9.0beta3\">"; \
echo "<!entity majorversion \"9.0\">"; \
} > version.sgml
"/usr/bin/perl" ./mk_feature_tables.pl YES ../../../src/backend/catalog/sql_feature_packages.txt
../../../src/backend/catalog/sql_features.txt> features-supported.sgml
"/usr/bin/perl" ./mk_feature_tables.pl NO ../../../src/backend/catalog/sql_feature_packages.txt
../../../src/backend/catalog/sql_features.txt> features-unsupported.sgml
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -c
/usr/share/sgml/docbook/dsssl-stylesheets/catalog-d stylesheet.dsl -t sgml -i output-html -V html-index postgres.sgml
LC_ALL=C "/usr/bin/perl" /usr/bin/collateindex.pl -f -g -i 'bookindex' -o bookindex.sgml HTML.index
Processing HTML.index...
1962 entries loaded...
0 entries ignored...
Done.
openjade -D . -D . -c /usr/share/sgml/docbook/dsssl-stylesheets/catalog -d ./stylesheet.dsl -t tex -V tex-backend -i
output-print-i include-index -V texpdf-output -V '%paper-type%'=USletter -o postgres-US.tex-pdf postgres.sgml
pdfjadetex postgres-US.tex-pdf
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
! I can't find file `postgres-US.tex-pdf'.
<*> postgres-US.tex-pdf
Please type another input file name:
===============================================
A simple ls command shows that there are no files under doc/src/sgml directory at this point. This was broken between
beta2and beta3.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
> I could build 9.0 Beta 3 A4 PDF without any issues, but I think something is broken in US PDF generation:
> This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
> %&-line parsing enabled.
> entering extended mode
> ! I can't find file `postgres-US.tex-pdf'.
> <*> postgres-US.tex-pdf
Hm. I'm not seeing that (on Fedora 13), but what I am seeing is that it
grinds for awhile and then fails with
[379.0.22
! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pdfstartlink.
<to be read again>
\endgroup \set@typeset@protect
l.280599 {1}}
You will want to use a version of GCC subsequent to 3.3.2,
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on postgres-US.log.
make: *** [postgres-US.pdf] Error 1
which is darn odd seeing that the -A4 version builds OK.
regards, tom lane
I wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
>> I could build 9.0 Beta 3 A4 PDF without any issues, but I think something is broken in US PDF generation:
>> This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
>> %&-line parsing enabled.
>> entering extended mode
>> ! I can't find file `postgres-US.tex-pdf'.
>> <*> postgres-US.tex-pdf
> Hm. I'm not seeing that (on Fedora 13), but what I am seeing is that it
> grinds for awhile and then fails with
> [379.0.22
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level than \pdfstartlink.
> <to be read again>
> \endgroup \set@typeset@protect
> l.280599 {1}}
> You will want to use a version of GCC subsequent to 3.3.2,
> ! ==> Fatal error occurred, no output PDF file produced!
> Transcript written on postgres-US.log.
> make: *** [postgres-US.pdf] Error 1
I find that removing the AIX-fixlevels table (and the two references to
it) from installation.sgml makes the postgres-US.pdf build go through on
my F-13 box. This is pretty weird, since there's nothing obviously
wrong with that table; and if there were something wrong with it, why
doesn't it bother the postgres-A4.pdf build? Seems like we must be
looking at a strange toolchain bug.
Now, ordinarily I wouldn't suggest removing information from the manual,
but I'm not sure that that table is worth fighting the toolchain for.
It was added here
http://archives.postgresql.org/pgsql-committers/2009-06/msg00197.php
on the basis of Laurenz Albe's suggestion here
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00884.php
but I don't know how carefully that was researched. I'm tempted to
propose going back to the "use the latest fixpack" wording that was
there before.
Comments? Can anyone else reproduce the behavior I'm seeing?
regards, tom lane
Tom Lane wrote: > I find that removing the AIX-fixlevels table (and the two references to > it) from installation.sgml makes the postgres-US.pdf build go through on > my F-13 box. This is pretty weird, since there's nothing obviously > wrong with that table; and if there were something wrong with it, why > doesn't it bother the postgres-A4.pdf build? Seems like we must be > looking at a strange toolchain bug. > > Now, ordinarily I wouldn't suggest removing information from the manual, > but I'm not sure that that table is worth fighting the toolchain for. > It was added here > http://archives.postgresql.org/pgsql-committers/2009-06/msg00197.php > on the basis of Laurenz Albe's suggestion here > http://archives.postgresql.org/pgsql-hackers/2009-06/msg00884.php > but I don't know how carefully that was researched. I'm tempted to > propose going back to the "use the latest fixpack" wording that was > there before. > > Comments? Can anyone else reproduce the behavior I'm seeing? I created the table based on known AIX bugs that affect getaddrinfo, and it's more than random numbers. Maybe the problem would go away if the information were not in a table, but in some other format, say, an unordered list. But I also see no big problem with returning to "use the latest fixpack". It is certainly a safe wording, although it will urge people to undergo the painful procedure of an upgrade even if that is unnecessary. Yours, Laurenz Albe
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes: > Tom Lane wrote: >> I find that removing the AIX-fixlevels table (and the two references to >> it) from installation.sgml makes the postgres-US.pdf build go through on >> my F-13 box. > Maybe the problem would go away if the information were not in a table, > but in some other format, say, an unordered list. Great idea --- I find that it works after transforming the table to a <variablelist>. I've committed a patch for that. Devrim, do you have time to see if CVS branch tip builds the PDFs ok for you? I've filed a complaint about the problem here: https://bugzilla.redhat.com/show_bug.cgi?id=619481 though I'm unsure whether Red Hat's maintainers will be able to help. regards, tom lane
On Thu, 2010-07-29 at 14:33 -0400, Tom Lane wrote: > Devrim, do you have time to see if CVS branch tip builds the PDFs ok > for you? Sure, working on it. -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
On Thu, 2010-07-29 at 14:33 -0400, Tom Lane wrote: > Devrim, do you have time to see if CVS branch tip builds the PDFs ok > for you? It built fine on 9.0 CVS tip. Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
> On Thu, 2010-07-29 at 14:33 -0400, Tom Lane wrote:
>> Devrim, do you have time to see if CVS branch tip builds the PDFs ok
>> for you?
> It built fine on 9.0 CVS tip.
Excellent, thanks for checking.
regards, tom lane
Tom Lane wrote: >>> I find that removing the AIX-fixlevels table (and the two references to >>> it) from installation.sgml makes the postgres-US.pdf build go through on >>> my F-13 box. >> >> Maybe the problem would go away if the information were not in a table, >> but in some other format, say, an unordered list. > > Great idea --- I find that it works after transforming the table to > a <variablelist>. I've committed a patch for that. Thank you, Tom. Yours, Laurenz Albe