gettext version problem exposed by buildfarm failures on "canary"

Started by Tom Laneover 16 years ago5 messages
#1Tom Lane
tgl@sss.pgh.pa.us

I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
but is failing to build HEAD, because msgfmt fails like this:

po/es.po:8039: keyword "msgid_plural" unknown
po/es.po:8036: missing `msgstr' section
po/es.po:8039: parse error

This indicates (1) canary needs a newer version of gettext, and
(2) our configure test for a sufficiently new gettext installation
is not in fact correct, because it didn't complain.

I asked about the configure issue some time ago, and was told that
the existing test for bind_textdomain_codeset() in libintl was
sufficient because that was introduced after ngettext(). It could
be that the library's history is different on NetBSD, or perhaps
canary has a recent libintl.so and a not so recent msgfmt.

I doubt it's worth trying to fix this before 8.4 release, but it
should get looked into eventually.

regards, tom lane

#2Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#1)
Re: gettext version problem exposed by buildfarm failures on "canary"

On Fri, June 26, 2009 9:34 am, Tom Lane wrote:

I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
but is failing to build HEAD, because msgfmt fails like this:

po/es.po:8039: keyword "msgid_plural" unknown
po/es.po:8036: missing `msgstr' section
po/es.po:8039: parse error

This indicates (1) canary needs a newer version of gettext, and
(2) our configure test for a sufficiently new gettext installation
is not in fact correct, because it didn't complain.

I asked about the configure issue some time ago, and was told that
the existing test for bind_textdomain_codeset() in libintl was
sufficient because that was introduced after ngettext(). It could
be that the library's history is different on NetBSD, or perhaps
canary has a recent libintl.so and a not so recent msgfmt.

I doubt it's worth trying to fix this before 8.4 release, but it
should get looked into eventually.

yes ... but presumably we don't want canary upgraded until we fix this,
unless we get some other test platform for it.

cheers

andrew

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#2)
Re: gettext version problem exposed by buildfarm failures on "canary"

"Andrew Dunstan" <andrew@dunslane.net> writes:

On Fri, June 26, 2009 9:34 am, Tom Lane wrote:

I doubt it's worth trying to fix this before 8.4 release, but it
should get looked into eventually.

yes ... but presumably we don't want canary upgraded until we fix this,
unless we get some other test platform for it.

What I'd suggest Kris do is temporarily disable the NLS option on that
build, so we can get at least some useful testing from the machine.
After a proposed configure fix has been installed, re-enable NLS, verify
configure fails as expected, *then* upgrade msgfmt.

regards, tom lane

#4Kris Jurka
books@ejurka.com
In reply to: Tom Lane (#1)
Re: gettext version problem exposed by buildfarm failures on "canary"

Tom Lane wrote:

I see buildfarm member "canary" (NetBSD 1.6) was recently resurrected,
but is failing to build HEAD, because msgfmt fails like this:

po/es.po:8039: keyword "msgid_plural" unknown
po/es.po:8036: missing `msgstr' section
po/es.po:8039: parse error

This indicates (1) canary needs a newer version of gettext, and
(2) our configure test for a sufficiently new gettext installation
is not in fact correct, because it didn't complain.

NetBSD has an odd mix of a BSD libintl and GNU msgfmt, so the library
provides both ngettext and bind_textdomain_codeset, but that has no
implications about what msgfmt supports.

pgfarm@netbsd:~$ msgfmt --version
msgfmt (GNU gettext) 0.10.35

Also, the man page for libintl says, "bind_textdomain_codeset() does not
work at this moment (always fail)."

So perhaps this platform is just a lost cause.

#5Kris Jurka
books@ejurka.com
In reply to: Tom Lane (#3)
Re: gettext version problem exposed by buildfarm failures on "canary"

Tom Lane wrote:

What I'd suggest Kris do is temporarily disable the NLS option on that
build, so we can get at least some useful testing from the machine.
After a proposed configure fix has been installed, re-enable NLS, verify
configure fails as expected, *then* upgrade msgfmt.

I disabled NLS, got a clean test run, and have now re-enabled nls so
that people can test things if they care.

Kris Jurka