Обсуждение: gettext version problem exposed by buildfarm failures on "canary"

Поиск
Список
Период
Сортировка

gettext version problem exposed by buildfarm failures on "canary"

От
Tom Lane
Дата:
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


Re: gettext version problem exposed by buildfarm failures on "canary"

От
"Andrew Dunstan"
Дата:
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



Re: gettext version problem exposed by buildfarm failures on "canary"

От
Tom Lane
Дата:
"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


Re: gettext version problem exposed by buildfarm failures on "canary"

От
Kris Jurka
Дата:
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.


Re: gettext version problem exposed by buildfarm failures on "canary"

От
Kris Jurka
Дата:
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