Closed tweerwag closed 9 years ago
Amusing. I've distilled this down to the following:
$ getopt --version
getopt from util-linux 2.25.388-819d9
$ LANG=nl_NL.utf8 getopt --version
'getopt' uit util-linux 2.25.388-819d9
And, fakeroot has the following logic to determine which flavor of getopt is available:
GETOPTEST=`getopt --version`
case $GETOPTEST in
getopt*) # GNU getopt
...
*) # POSIX getopt ?
...
So this now fails because a translator decided to add superfluous decorations. Looking at the PO files, this is equally broken in tr_TR.utf8 where the word order has been localized:
$ LANG=tr_TR.utf8 getopt --version
util-linux 2.25.388-819d9 deki getopt
While I'm disappointed by fakeroot's brittle detection mechanism, parsing version strings isn't an uncommon thing to do for programs which insist on being highly portable. I think this is a util-linux bug to allow translations of such strings. @karelzak, thoughts about removing this?
In the meantime, I'm just going to bandaid mkaurball (which will be dead, anyways, with pacman 4.3).
Fixed by 220a1b4dfbd53768ed1ee6eebe728dcf4f565827
On Tue, Nov 11, 2014 at 05:11:22AM -0800, Dave Reisner wrote:
While I'm disappointed by fakeroot's brittle detection mechanism, parsing version strings isn't an uncommon thing to do for programs which insist on being highly portable. I think this is a util-linux bug to allow translations of such strings. @karelzak, thoughts about removing this?
Well, we don't have any procedure to check translations and I have doubts it's possible to implement something usable for this purpose. Maybe in some languages add extra chars makes sense (for example to avoid misinterpretation of the untranslated words).
It would be better to discuss this topic on util-linux mailing list.
Karel
Karel Zak kzak@redhat.com http://karelzak.blogspot.com
Running mkaurball on any package with LANG=nl_NL.utf8 yields: (with translations between the brackets.)
It is caused by
on lines 98-102 of mkaurball.in. It seems that the command following '-c' is broken down in several arguments before being passed to sh. Changing that line to
fixes the issue for me. (But I don't know if this is a proper fix.) Somehow, this doesn't occur with LANG=C or LANG=en_US.utf8.