Hi all,

Gesendet: Mittwoch, 08. Juli 2015 um 16:49 Uhr Von: "Andreas Schwab" An: "Axel Braun" Cc: opensuse-packaging@opensuse.org Betreff: [opensuse-packaging] Re: Some trouble with language files

...

- Why are the .mo files compiled without error (of course, this should be the standard case...)?

Does this step use msgfmt?

the command 'compile_catalog' in python setup.py compile_catalog is imported from python-babel - I assume it uses something similar, or even the python implementation of msgfmt. Sorry, I'm just packing, not programming. Best regards Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Gesendet: Donnerstag, 09. Juli 2015 um 14:50 Uhr Von: "Andreas Schwab" An: "Axel Braun" Cc: opensuse-packaging@opensuse.org Betreff: [opensuse-packaging] Re: Aw: Re: Some trouble with language files

...

...

...

- Why are the .mo files compiled without error (of course, this should be the standard case...)?

Does this step use msgfmt?

the command 'compile_catalog' in python setup.py compile_catalog is imported from python-babel - I assume it uses something similar, or even the python implementation of msgfmt. Sorry, I'm just packing, not programming.

That may be the answer to your first question.

Which one does 'That' refer to? python-babel or not programming`? In fact only some language files are effected by this error message, not all. /Ax -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am Donnerstag, 9. Juli 2015, 15:07:58 schrieb Andreas Schwab:

"Axel Braun" writes:

...

...

Gesendet: Donnerstag, 09. Juli 2015 um 14:50 Uhr Von: "Andreas Schwab" An: "Axel Braun" Cc: opensuse-packaging@opensuse.org Betreff: [opensuse-packaging] Re: Aw: Re: Some trouble with language files

...

...

...

- Why are the .mo files compiled without error (of course, this should be the standard case...)?

Does this step use msgfmt?

the command 'compile_catalog' in python setup.py compile_catalog is imported from python-babel - I assume it uses something similar, or even the python implementation of msgfmt. Sorry, I'm just packing, not programming.>> That may be the answer to your first question.

Which one does 'That' refer to? python-babel or not programming`? In fact only some language files are effected by this error message, not all. If the python implementation is inferior then you have the answer.

I doubt it is - more the question, why does the RPM script treats the error that severe? /Ax -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Thu, 9 Jul 2015, Axel Braun wrote:

...

...

...

...

...

> - Why are the .mo files compiled without error (of course, this > should be the standard case...)?

Does this step use msgfmt?

the command 'compile_catalog' in python setup.py compile_catalog is imported from python-babel - I assume it uses something similar, or even the python implementation of msgfmt. Sorry, I'm just packing, not programming.>> That may be the answer to your first question.

Which one does 'That' refer to? python-babel or not programming`? In fact only some language files are effected by this error message, not all. If the python implementation is inferior then you have the answer.

I have my doubts....I checked the file with poedit and then run msgfmt on it, result:

docb@T520:~/tryton/tryton-3.6.1/b/share/locale/nl_NL/LC_MESSAGES> msgfmt -v -c tryton.po 278 übersetzte Meldungen, 61 ungenaue Übersetzungen, 63 unübersetzte Meldungen.

I use the .mo file generated by msgfmt, but still the error remains: [ 19s] + /usr/lib/rpm/find-lang.sh /home/abuild/rpmbuild/BUILDROOT/tryton-3.6.1-0.i386 tryton --without-C [ 19s] removing translation /usr/share/locale/nl_NL/LC_MESSAGES/tryton.mo: 278 translated messages.

There is no error in the above. The "removing translation" are informative. The error is this from your original log: "<stdin>:81: 'msgid' and 'msgstr' entries do not both end with '\n'" and that means that "msgunfmt $file | msgfmt --statistics -o /dev/null" is breaking, and that means that $file was incorrectly generated when the initial build didn't already complain. So yes, it's the python implementation of msgfmt that's broken. Ciao, Michael.

Am Donnerstag, 9. Juli 2015, 20:59:14 schrieb Axel Braun:

...

...

...

...

...

>> > - Why are the .mo files compiled without error (of course, >> > this >> > should be the standard case...)? >> >> Does this step use msgfmt? > > the command 'compile_catalog' in > python setup.py compile_catalog > is imported from python-babel - I assume it uses something > similar, > or > even the python implementation of msgfmt. Sorry, I'm just > packing, > not > programming.>>

That may be the answer to your first question.

Which one does 'That' refer to? python-babel or not programming`? In fact only some language files are effected by this error message, not all.

If the python implementation is inferior then you have the answer.

I have my doubts....I checked the file with poedit and then run msgfmt on it, result:

docb@T520:~/tryton/tryton-3.6.1/b/share/locale/nl_NL/LC_MESSAGES> msgfmt -v -c tryton.po 278 übersetzte Meldungen, 61 ungenaue Übersetzungen, 63 unübersetzte Meldungen.

I use the .mo file generated by msgfmt, but still the error remains: [ 19s] + /usr/lib/rpm/find-lang.sh /home/abuild/rpmbuild/BUILDROOT/tryton-3.6.1-0.i386 tryton --without-C [ 19s] removing translation /usr/share/locale/nl_NL/LC_MESSAGES/tryton.mo: 278 translated messages.

There is no error in the above. The "removing translation" are informative.

Exactly! But my latest comment does not refer to the original message! I removed all languages in error from the tarball, just left one language in, and edited this with poedit, and generated an mo file with msgfmt. And the output of msgfmt -v -c tryton.po returned no errors

...

The error is this from your original log: "<stdin>:81: 'msgid' and 'msgstr' entries do not both end with '\n'" and that means that "msgunfmt $file | msgfmt --statistics -o /dev/null" is breaking, and that means that $file was incorrectly generated when the initial build didn't already complain.

docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/nul msgfmt: Eingabedatei fehlt »msgfmt --help« gibt weitere Informationen.

...

So yes, it's the python implementation of msgfmt that's broken.

Probably not. But bottom line is that msgfmt does not issue an error, while %find_lang removed the .mo file.... Strange

...and even more weird. If I run the find-lang script against the sources it works like charm: T520:/var/tmp/build-root/openSUSE_13.1- i586/home/abuild/rpmbuild/BUILD/tryton-3.6.1/share/locale/nl_NL # /usr/lib/rpm/find-lang.sh /var/tmp/build-root/openSUSE_13.1- i586/home/abuild/rpmbuild/BUILD/tryton-3.6.1 tryton find: ‘/var/tmp/build-root/openSUSE_13.1- i586/home/abuild/rpmbuild/BUILD/tryton-3.6.1/usr/share/locale/’: Datei oder Verzeichnis nicht gefunden find: ‘/var/tmp/build-root/openSUSE_13.1- i586/home/abuild/rpmbuild/BUILD/tryton-3.6.1/usr/share/help/’: Datei oder Verzeichnis nicht gefunden The tryton.lang file that was created: %defattr (644, root, root, 755) %lang(cs) /share/locale/cs_CZ/LC_MESSAGES/tryton.mo %lang(de) /share/locale/de_DE/LC_MESSAGES/tryton.mo %lang(es) /share/locale/es_AR/LC_MESSAGES/tryton.mo %lang(es) /share/locale/es_CO/LC_MESSAGES/tryton.mo %lang(es) /share/locale/es_EC/LC_MESSAGES/tryton.mo %lang(es) /share/locale/es_ES/LC_MESSAGES/tryton.mo %lang(fr) /share/locale/fr_FR/LC_MESSAGES/tryton.mo %lang(nl) /share/locale/nl_NL/LC_MESSAGES/tryton.mo %lang(ru) /share/locale/ru_RU/LC_MESSAGES/tryton.mo %lang(sl) /share/locale/sl_SI/LC_MESSAGES/tryton.mo -> contains the nl_NL entry that was causing the trouble. Is this an OBS error then? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Thu, 9 Jul 2015, Axel Braun wrote:

...

...

docb@T520:~/tryton/tryton-3.6.1/b/share/locale/nl_NL/LC_MESSAGES> msgfmt -v -c tryton.po 278 übersetzte Meldungen, 61 ungenaue Übersetzungen, 63 unübersetzte Meldungen.

I use the .mo file generated by msgfmt, but still the error remains: [ 19s] + /usr/lib/rpm/find-lang.sh /home/abuild/rpmbuild/BUILDROOT/tryton-3.6.1-0.i386 tryton --without-C [ 19s] removing translation /usr/share/locale/nl_NL/LC_MESSAGES/tryton.mo: 278 translated messages.

There is no error in the above. The "removing translation" are informative.

Exactly! But my latest comment does not refer to the original message!

Hmm? You have an error message on files generated by pythons msgfmt replacement. Then you have used msgfmt itself on the files and found no error messages. Why do you still think it's not pythons variant that is buggy?

I removed all languages in error from the tarball, just left one language in, and edited this with poedit, and generated an mo file with msgfmt. And the output of msgfmt -v -c tryton.po returned no errors

That's the point. It's the .mo files generated by pythons msgfmt that contain errors, not the original .po files. So you generating the .mo files with proper msgfmt (not pythons variant) "fixes" the problem.

...

The error is this from your original log: "<stdin>:81: 'msgid' and 'msgstr' entries do not both end with '\n'" and that means that "msgunfmt $file | msgfmt --statistics -o /dev/null" is breaking, and that means that $file was incorrectly generated when the initial build didn't already complain.

docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/nul msgfmt: Eingabedatei fehlt »msgfmt --help« gibt weitere Informationen.

Yeah, well, obviously that's not the correct command to use, I abbreviated, you have to apply a little thinking. the actual command line would be: % msgunfmt tryton.mo | msgfmt --statistics -o /dev/null - (Use the .mo file generated from the python msgfmt, _not_ the one you generated yourself with msgfmt)

...

So yes, it's the python implementation of msgfmt that's broken.

Probably not. But bottom line is that msgfmt does not issue an error, while %find_lang removed the .mo file....

The .mo files aren't removed because of the error but because they are for non-supported languages. Supported languages are all those that have an entry under /usr/share/locale/ in the 'filesystem' package; all others are not supported. 'nl_NL' is one of those non-supported languages. Ciao, Michael.

Hi, I try to consolidate the last posts.... Am Freitag, 10. Juli 2015, 14:11:58 schrieb Michael Matz:

...

...

There is no error in the above. The "removing translation" are informative.

Exactly! But my latest comment does not refer to the original message!

Hmm? You have an error message on files generated by pythons msgfmt replacement. Then you have used msgfmt itself on the files and found no error messages. Why do you still think it's not pythons variant that is buggy?

Because the .mo gets removed in both cases - the .mo included in the original tarball, as well as the handcrafted .mo

...

...

The error is this from your original log: "<stdin>:81: 'msgid' and 'msgstr' entries do not both end with '\n'" and that means that "msgunfmt $file | msgfmt --statistics -o /dev/null" is breaking, and that means that $file was incorrectly generated when the initial build didn't already complain.

docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/nul msgfmt: Eingabedatei fehlt »msgfmt --help« gibt weitere Informationen.

Yeah, well, obviously that's not the correct command to use, I abbreviated, you have to apply a little thinking. the actual command line would be:

and some more bash-knowledge I assume :-)

% msgunfmt tryton.mo | msgfmt --statistics -o /dev/null -

(Use the .mo file generated from the python msgfmt, _not_ the one you generated yourself with msgfmt)

OK, back to start, back to the original tarball with the python-generated .mo file. Here is the output: docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/null - 338 übersetzte Meldungen. (no error, just the number of translated messages)

...

...

So yes, it's the python implementation of msgfmt that's broken.

Probably not. But bottom line is that msgfmt does not issue an error, while %find_lang removed the .mo file....

The .mo files aren't removed because of the error but because they are for non-supported languages. Supported languages are all those that have an entry under /usr/share/locale/ in the 'filesystem' package; all others are not supported. 'nl_NL' is one of those non-supported languages.

I see. Now I understand Yamaban's comment as well - or at least I think I do: Because the openSUSE standard installation does not have a nl_NL entry, the language gets removed during build, did I get that right? Did a quick check, did the rename nl_BE -> nl_NL (in the build environment), but that did not fix it. Stuck again :-( Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Good morning,

Gesendet: Freitag, 10. Juli 2015 um 16:16 Uhr Von: Yamaban An: opensuse-packaging Betreff: [opensuse-packaging] Re: Re: Aw: Re: Re: Some trouble with language files

[snip]

...

Did a quick check, did the rename nl_BE -> nl_NL (in the build environment), but that did not fix it.

Nooooo! Wrong! (Sorry, I'll drop the drama)

Lecture-hat on:

"nl_BE" is Netherland speech, Belgian Nation (curency, measurements, etc) "nl_NL", or "nl" for short is Netherland speech, Netherland Nation, Netherlands for short, but there will be outlaws for some languages

Yes, no problem with that

see "de_CH", "de_AT", and "de" for easy to understand example. IOW: let "nl_BE" be as it is, only touch "nl_NL" dir (mv nl_NL nl)

And here is where I suffer to understand: nl_NL is a permitted locale: http://lh.2xlibre.net/locale/nl_NL/ What is the point in changing *everything* to nl? - the translation language in the .po - the definition in setup.py - the directory naming in tryton/share/locale/nl_NL So if everything points to nl, it builds, if it points to nl_NL, it does not. Because in /usr/share/locale there is no nl_NL entry? Confused... Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org