Summary: | xmms-1.2.7-r22 Fails to build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Lisa Seelye (RETIRED) <lisa> |
Component: | [OLD] GNOME | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | brad, deviantgeek, fede2, Jan.Schubert, koshka, pauldv, sound |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | xmms-fix.diff (A patch that fixes xmms) |
Description
Lisa Seelye (RETIRED)
![]() not a gnome bug Confirmed. This is happening because of gettext 0.12.x I think. As the message says, there are a some caracters that xgettext doens't like that mutch. It happens on Input/tonegen/tonegen.c (line 50), Input/vorbis/vorbis.c (line 610) and in xmms/about.c on several ocations. The thing is that --from-code=iso-8859-1 should be added. I think that a --language=C would be apropiate, since I _think_ that xgettext is trying to get into C comments as well, but this las comment can be safely ignored :). I'm so sorry. Didn't made myself clear about this :). That argument should be added to xgettext like: PATH=../src:$PATH /usr/bin/xgettext --default-domain=xmms --directory=.. --add-comments --keyword=_ --keyword=N_ --files-from=./POTFILES.in --language=C --from-code=iso-8859-1 Doesn't help. I edited po/Makefile for xgettext to use --language=C and --from-code=iso8859-1, still the same error. make[2]: Entering directory `/tmp/portage/xmms-1.2.7-r22/work/xmms-1.2.7/po' PATH=../src:$PATH /usr/bin/xgettext --default-domain=xmms --directory=.. \ --add-comments --keyword=_ --keyword=N_ \ --files-from=./POTFILES.in --language=C --from-code=iso8859-1 \ && test ! -f xmms.po \ || ( rm -f ./xmms.pot \ && mv xmms.po ./xmms.pot ) /usr/bin/xgettext: Non-ASCII string at Input/tonegen/tonegen.c:50. Please specify the source encoding through --from-code. mv: cannot stat `xmms.po': No such file or directory make[2]: *** [xmms.pot] Error 1 make[2]: Leaving directory `/tmp/portage/xmms-1.2.7-r22/work/xmms-1.2.7/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/portage/xmms-1.2.7-r22/work/xmms-1.2.7' make: *** [all-recursive-am] Error 2 You set the input to iso8859-1 while it should be iso-8859-1 (note the extra dash) Adding --language=C and --from-code=iso-8859-1 to the po/Makefile fixes this problem. (Quick fix for users) tar xvzf /usr/portage/distfiles/xmms-1.2.7.tar.gz nano xmms-1.2.7/po/Makefile.in.in Change line 88 from: $(XGETTEXT) --default-domain=$(PACKAGE) --directory=$(top_srcdir) \ to $(XGETTEXT) --default-domain=$(PACKAGE) --directory=$(top_srcdir) --language=C --from-code=iso-8859-1 \ Tar it back up: tar cvzf xmms-1.2.7.tar.gz xmms-1.2.7/ mv xmms-1.2.7.tar.gz /usr/portage/distfiles/ ebuild /usr/portage/media-sound/xmms/xmms-1.2.7-r22.ebuild digest emerge xmms be happy -P Created attachment 14540 [details, diff]
xmms-fix.diff (A patch that fixes xmms)
I've added a patch that should fix things when applied in
/usr/portage/media-sound/xmms (or the cvs location). It basic does what is
suggested here.
Isn't there an environment variable that can be set? LANG or something similar. Would that have the same effect, or is that a different case? According to the xgettext manual and info pages there is no such environment variable. This option specifies the input encoding, making it depend on the local locale might be counterproductive. *** Bug 24708 has been marked as a duplicate of this bug. *** I don't intend to offend -- it's just that I added a patch to add /usr/local/share/xmms/Skins to the skins search path and was pointed to this bug, for which pauldv provided a patch above. Thinking to kill 2 birds with one stone, I reassigned this bug to myself, in order to close it. -r23 in portage. The bug is _not_ fixed (for me) in -r23! initially wasn't -- rsync again and try please According to the gentoo-Netiquette i'm not allowed to rsync more than one time a day :-). So, why is it not called -r24? why should it be called -r24? (yeah, I know about netiquette, but please do it anyway this time) 'cause you obviousally changed something (without renaming) it wasn't a change to add anything -- it was a change to fix something -- a fix, which affects only some of the users, not all is -r23 failing for everybody? No. -r23 works for me, just fine. I'm on ~x86. r23-r2 seems also working for me closing again. |