Hi, after emerging gal 0.21 no umlauts (
Hi, after emerging gal 0.21 no umlauts (öäüß) are working in gabber (and maybe other applications). They appear as an underscore Reverting to gal 0.20-r1 solves the problem ;) Bye
One of the "maybe other applications" is evolution. Not only umlauts are not working, there are whole messages and parts of menus missing. I also reverted to gal 0.20-r1.
I can't reproduce this bug with either gabber or evolution. Could you elaborate some more on the settings of your machine (the output of `emerge info' would be helpful) and the versions of every relevant package? Thanks
http://bugzilla.ximian.com/show_bug.cgi?id=33489
Created attachment 6395 [details] screenshot showing several errors caused by gal-0.21
Ah, I am not familiar with bugzilla, my comment got lost to the attachment. Yesterday I upgraded to fosers gnome-2.1.3 ebuilds he posted in the forums, so that are my versions of all the relevant packages. I also upgraded to evolution-1.2.0-r1. The error is still there. My emerge info: Portage 2.0.45-r3 (default-1.0, gcc-2.95.3, glibc-2.2.5-r7) ================================================================= System uname: 2.4.19-gentoo-r10 i686 Pentium III (Katmai) USE="x86 oss apm avi crypt cups jpeg libg++ mikmod ncurses pdflib qtmt spell truetype xml2 xmms xv berkdb bonobo cdr esd gdbm gif gnome-libs gtk gtkhtml guile imlib java libwww mozilla nls oggvorbis opengl pam perl png python readline sdl slang ssl tcltk tcpd tetex tiff X -kde -arts gnome mysql -postgres -ipv6 -gpm -pda -svga nvidia nv -3dnow sse mmx evo dvd encode mpeg -motif -ldap -quicktime -qt" ARCH="x86" COMPILER="" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -ffast-math -pipe -fomit-frame-pointer" CXXFLAGS="" ACCEPT_KEYWORDS="x86 ~x86" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" MAKEOPTS="-j2" JDK_HOME="/opt/sun-jdk-1.4.1.01" JAVA_HOME="/opt/sun-jdk-1.4.1.01" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" GENTOO_MIRRORS="http://www.ibiblio.org/gentoo" Hth, Kai.
Yes, because this is all gnome/gtk1 stuff. Evolution 1.2 won't work with gal<0.21 though. Looks very much like a gal problem, i also read somewhere that the Gabber maintainers always stressed that any char conversion problems should be reported to the gal maintainers and not Gabber, because they couldn't do anything about it.
What are your langauge settings ?
LANG and LC_* is set to de_DE@euro. Ah, and to point it out: the problem also happened with regular gnome2.0.x and evolution 1.0.8. Changing gal triggered or fixed the problem. Well, now that I think of it, I should just have played a little with my language settings. It's not that I need german menus *that* urgent. :-)
update: it doesn't seem to be a gal problem per se, because on a new from scratch installation with a newer gal, I don't have the problem. So probably it's caused by another library that should be updated when gal is updated.
with a newer gal ? you mean 0.22 ? maybe this problem got fixed, anyone who can confirm that ?
No I can't confirm this... I have the same problem with gal 0.22 (even after a emerge -e world)... at least with gabber... I don't use Evolution
*** Bug 13630 has been marked as a duplicate of this bug. ***
*** Bug 13641 has been marked as a duplicate of this bug. ***
These problems happens too with french language.
These problems happens too with french language, but Evolution was freezing too. I use this workaround export LANG="C" export LANGUAGE="C" export LC_ALL="C" evolution & I works only for the main interface, and Evolution no more freeze, but labels are missing in many dialog box
All you that experience problems be sure to killev oaf-slay before you try a workaround.
I have yet set kill-ev but I didn't know know oaf-slay, thanks
In Norwegian in evolution no message with the special characters (
In Norwegian in evolution no message with the special characters (æøåÆØÅ) is visible. If other messages that not contain this special characters is not visible too is unknown.
*** Bug 13873 has been marked as a duplicate of this bug. ***
Can someone try to debug this? I can't really reproduce it and don't have time to really look into it, but i suppose someone CCed on this bug has enough knowledge to find something/patch it.
*** Bug 13966 has been marked as a duplicate of this bug. ***
I tried everything I could think about. Re emerged evolution -e tried tweaking locale.alias install or re install libraries I even looked a little at the code, but it is huge between evolution and dependancy. The only workaround that worked, is to have a locale defined in /usr/share/locale/locale.alias. I'm stopping to look into it before I get mad :), I will try next week again I think. Maybe someone should post something on Ximian bugzilla, or gnome.
Hi, the same problems here. But after compiling Evolution with USE="-nls" everything works fine. Hope this helps.
Does "work fine" include native language support or does this USE="-nls" simply change the language in text messages to english?
I tried with USE="-nls". The app is then in english. Well, almost. With locale "fr_FR@euro", in compose, some of my menus were still in french, and those with non us-ascii characters were not showing. With locale "french", same behaviour, but menus (the one in compose, not all) were showing, and in french. Btw, menus are a melange of french and english, very weird. Tried with USE="nls", but made a new ebuild, and added the switch --with-included-gettext, it didn't work either.
FYI, sodipodi also suffers from the dissappearing menu problem. This problem disappears when compiling with USE="-nls", but then of course all the menus are in English.
please Try to set your locale settings to LANG=fr_FR LC_ALL=fr_FR and all other unset... there can be problem with @euro sign Proper (by the iso norm) setting of codepage with euro is fr_FR.ISO-8859-15 plain fr_FR uses ISO-8859-1 codepage... be sure you have the font which HAS this codepage !!! fonts.dir file can be your help... before starting up the evolution please confirm by $ set command that only the LANG and LC_ALL is setuped
Tried what you said, problem is the same. the ONLY locales working (so far) are the alias ones in /usr/share/locale/locale.alias. Btw, same problem with Gnucash.
I really think it's a bug in gtkhtml. Best to test it with gnucash. As long as you do not open the help, everything is ok. But when you open it, all label with accented chars disappear. Here is the relevant info (I think) I found on Ximian bugzilla: http://bugs.ximian.com/show_bug.cgi?id=37326 http://bugs.ximian.com/show_bug.cgi?id=36449 I'm trying to see if I can resolve the bug, but I'm really new to the gtkhtml code, and gnome/gtk stuff. So don't expect anything, really.
For the aventurous, try to add the following line to /usr/portage/x11-libs/gtk+/gtk+-1.2.10-r9.ebuild inherit eutils before IUSE="nls" and the following line epatch ${FILESDIR}/1.2.10/gtk+-1.2.10-encoding.patch between cd ${S}/.. and bzcat ${DISTDIR}/gtk+-1.2.10-r8-gentoo.diff.bz2 | patch -p0 . put http://twanger.dyndns.org/gtk+-1.2.10-encoding.patch in /usr/portage/x11-libs/gtk+/files/1.2.10, run ebuild /usr/portage/x11-libs/gtk+/gtk+-1.2.10-r9.ebuild digest and emerge \=gtk+-1.2.10-r9 and look if you have umlauts. I do. I got the patch from the source rpm in RedHat phoebe. I know that it doesn't apply cleanly.
Looking at strace output of evolution, I have found strange command: open /usr/lib/locale/<my_language>/LC_CTYPE This file was present for glibc-2.2.5, but no more in glibc-2.3. However, trying to recompile all dependent libraries (which can contain statically linked old code) does not help. I am able to repeat similar problems (with same strace) in sodipodi and (after upgrade to latest unstable glibc) also xmms.
yes.. glibc < 2.3 has the locale messages in /usr/lib/locale directory new glibc > 2.3 has the catalog file in this directory, and messages in /usr/share/locale I suppose there is hard openning of message defined in source code ... but it need's digging...
according to ./configure --help you can setup --with-native-locale which means it will use the glibc func locale, but I have no idea if gentoo uses this flag or not...
SuSE devel has following components: evolution-1.2.2 gal-0.23 gtkhtml-1.1.8 soup-0.7.11 glibc-2.3.2 No special patches (except glibc) and everything works OK. Please also see bug 16816 (update of sub-components, released by Ximian for use with evolution-1.2.2). I have done another test: mkfifo /usr/lib/locale/<my_language>/LC_CTYPE #(trick to freeze app) gdb evolution Call was done from setlocale() (i. e. glibc), which was from inside gal! Following test also works correctly (and without touching this file): #include <stdlib.h> #include <stdio.h> #include <locale.h> #include <ctype.h> void pisalpha(char c) { if (isalpha (c)) printf ("The character `%c' is alphabetic.\n", c); else printf ("The character `%c' is not alphabetic.\n", c); } int main () { setlocale(LC_CTYPE, "cs_CZ"); pisalpha('a'); pisalpha('
SuSE devel has following components: evolution-1.2.2 gal-0.23 gtkhtml-1.1.8 soup-0.7.11 glibc-2.3.2 No special patches (except glibc) and everything works OK. Please also see bug 16816 (update of sub-components, released by Ximian for use with evolution-1.2.2). I have done another test: mkfifo /usr/lib/locale/<my_language>/LC_CTYPE #(trick to freeze app) gdb evolution Call was done from setlocale() (i. e. glibc), which was from inside gal! Following test also works correctly (and without touching this file): #include <stdlib.h> #include <stdio.h> #include <locale.h> #include <ctype.h> void pisalpha(char c) { if (isalpha (c)) printf ("The character `%c' is alphabetic.\n", c); else printf ("The character `%c' is not alphabetic.\n", c); } int main () { setlocale(LC_CTYPE, "cs_CZ"); pisalpha('a'); pisalpha(''); pisalpha('č'); pisalpha('ý'); exit(0); }
Created attachment 8962 [details, diff] gtkhtml-hardcode-charset.diff Ad #29: http://bugs.ximian.com/show_bug.cgi?id=36449 (default charset detection does not work) is different bug and has simple workaround for XFree86-4 (I am attaching) - forcing iso10646-1 fonts for gtkhtml (can be done by user in Preferences or gnomecc). The fix can be included to Gentoo for builds with server with such fonts and ability to use 16-bit fonts (note: it is merge of two patches).
Finally, after few hours of work, I have located this bug - no bug in gal, no bug in evolution, but bugs in gtk+ and glibc includes: This is a situation, when gal tries to open bad locale. It is too late now, because someone else has mangled it: #0 0x40ff2504 in open () from /lib/libc.so.6 #1 0x4104d20c in __DTOR_END__ () from /lib/libc.so.6 #2 0x40f47455 in _nl_find_locale () from /lib/libc.so.6 #3 0x40f46856 in setlocale () from /lib/libc.so.6 #4 0x4034ffbd in e_iconv_init () from /usr/lib/libgal.so.21 #5 0x4034fe60 in e_iconv_locale_charset () from /usr/lib/libgal.so.21 #6 0x40375a78 in e_utf8_from_locale_string_sized () from /usr/lib/libgal.so.21 #7 0x40375af4 in e_utf8_from_locale_string () from /usr/lib/libgal.so.21 #8 0x40351cf2 in e_utf8_gettext () from /usr/lib/libgal.so.21 #9 0x0806aed8 in e_local_storage_get_corba_interface () #10 0x0806a84b in e_local_storage_open () #11 0x08089ee9 in e_shell_construct_result_to_string () #12 0x0808782a in e_shell_construct () #13 0x08087c41 in e_shell_new () #14 0x0809d057 in main () #15 0x40df752f in g_idle_dispatch () from /usr/lib/libglib-1.2.so.0 #16 0x40df7bde in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #17 0x40df79aa in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #18 0x40df6954 in g_main_run () from /usr/lib/libglib-1.2.so.0 #19 0x40cf4977 in gtk_main () from /usr/lib/libgtk-1.2.so.0 #20 0x4016e60e in bonobo_main () from /usr/lib/libbonobo.so.2 #21 0x0809ce11 in main () #22 0x40f3cdc4 in __libc_start_main () from /lib/libc.so.6 Bug 1: Bad glibc header. extern char *setlocale (int __category, __const char *__locale) __THROW; should be extern const char *setlocale (int __category, __const char *__locale) __THROW; Bug 2: Bug in gentoo patch (and probably also GNOME CVS): it is enough to remove everything, which patches gtkrc.c I will fill proper bug reports soon. You can verify it by following patch: --- gal-0.23/gal/util/e-iconv.c.orig 2002-09-26 19:34:26.000000000 +0200 +++ gal-0.23/gal/util/e-iconv.c 2003-03-05 00:20:46.000000000 +0100 @@ -198,9 +198,10 @@ gchar *old_locale; old_locale = g_strdup (setlocale (LC_CTYPE, NULL)); - setlocale (LC_CTYPE, "C"); +// setlocale (LC_CTYPE, "C"); + printf ("DEBUG C_g_strdown: old_locale is %s\n", old_locale); g_strdown (string); - setlocale (LC_CTYPE, old_locale); +// setlocale (LC_CTYPE, old_locale); g_free (old_locale); } @@ -211,6 +212,9 @@ char *from, *to, *locale; int i; + printf ("DEBUG e_iconv_init: LC_CTYPE is %s\n", setlocale (LC_CTYPE, NULL)); + printf ("DEBUG e_iconv_init: LC_MESSAGES is %s\n", setlocale (LC_MESSAGES, NULL)); + LOCK(); if (iconv_charsets != NULL) {
nice work, Stando... :)
Bug 16883 was actually created. This bug is consequence of this bug and can be closed.
Additional note to #36 - glibc headers: The glibc documentation clearly states, that you must make your own copy of the string. Since the return value of setlocale is not const (which is also mentioned in the glibc documentation), change would be wrong. This is a very old discussion and glibc maintainers does not accept any changes to this.
Added gtk+-1.2.10-r10 , with the added patch as provided in bug #16883 . Note that this same solution was already available in the patch mentioned in comment #30 . Please give it a go, so we can mark it stable asap. Big thanks to mr. Brabec for getting to the bottom of this.
thanks so much ;) just merged gtk+-1.2.10-r10 and all empty menus/buttons in my gtk+ 1.2 apps are gnone and using copy&paste with umlauts in gtk+ 1 apps now works, too.
Tried with evolution and Gnucash. Work as intented now.
tried with evolution, devhelp and gnucash! Works just fine! By the way, devhelp had the same problem because it depends on gtkhtml who depends on gal who depends on gtk+ :-)
marked gtk+-1.2.10-r10 stable for x86, added CC archs please test and do as well. The change is minor, but fixes an annoying bug for localized users. /me hopes this CCing works :)
compiles clean here and seems to work fine, I'll mark it ppc now, thanks :)
archs please mark stable as requested .
