Bug 539904

Created attachment 372746 [details]
Attached traceback automatically from anaconda.

This happened to me when I tried to kickstart a VM using cobbler.
It only happens to me when the system locale is set to de_DE.

same problem with french language (Fedora 12 i386 DVD .iso)

same here with: lang de_DE.UTF-8

Created attachment 376204 [details]
Attached traceback automatically from anaconda.

this bug depends on the text mode for installation; using the graphical installer shows no problem with german or other locale, only using text mode (simply add "text" to the boot params) will throw this traceback when selecting german locale, e.g.
This was tested on two different machines, with the same result when using text mode.

I can confirm that anaconda crashes with kickstart options "text" and "lang de_DE".
It works proberly without kickstart options "text".

The reason for using text mode in previous fedora versions were problems with graphical mode with some graphic cards. By using text mode we always see an output on the display during installation, in contrast to a black or unreadable output with some graphic cards.

Is there a chance to create an update script for kickstart installation (to put in an update directory on the install image)?

Created attachment 381427 [details]
Attached traceback automatically from anaconda.

Created attachment 383638 [details]
Evil hack to disable translation in system-config-date

I've created an evil hack patch that disables the translation stuff in the system-config-date package. 

Using this patch I'm able to spin a german install CD in text mode.
Too bad I'm not a python developer to fix this properly :(

you can see this: https://bugzilla.redhat.com/show_bug.cgi?id=538328

Created attachment 387800 [details]
Attached traceback automatically from anaconda.

Created attachment 395342 [details]
Attached traceback automatically from anaconda.

Created attachment 398169 [details]
Attached traceback automatically from anaconda.

Created attachment 398660 [details]
Attached traceback automatically from anaconda.

Created attachment 398904 [details]
Attached traceback automatically from anaconda.

Created attachment 399273 [details]
Attached traceback automatically from anaconda.

Same here with Czech language (cs_CZ).

Created attachment 400878 [details]
Attached traceback automatically from anaconda.

13-Beta.TC0 still has the problem. Installation in text interface is impossible in other languages. Only English language works.

It seems like candidate for blocking bug for Beta.

Added as F13Beta blocker bug and changed Version to 13.
This bug essentially prevents any non-English Textmode Installs

Here's what's *probably* going on:
in s-c-date, in zonetab.py, this code is called:
  translated = reduce(lambda x, y: x.replace(y, "/"), self._slash_lookalikes,   translated)
where translated is of type string and _slash_lookalikes is a list of unicodes. replace needs to decode translated into a unicode so the replacing can take place. it has no clue what translated's encoding is but it assumes it's the one from sys.getdefaultencoding() and that makes perfect sense. Unfortunately in anaconda we never set this to antyhing, so it's ascii, thus the traceback (i.e. python knows it's looking at an encoded unicode but at the same time it is not ascii so it bombs).

Why it does not happen during graphical install:
because we do 'import gtk' which has a nasty side-effect of setting the default encoding to 'utf8', see: https://bugzilla.gnome.org/show_bug.cgi?id=132040
BTW, the exact same thing happens when s-c-date is called standalone on an installed system.

Cut the story short and get to the root cause:
The default encoding in python is ascii during text install and not utf8.

What the fix is going to be like:
1) if we can figure out a way to have sys.setdefaultencoding('utf8') called before anaconda starts we're golden.
2) otherwise we would need to import gtk, even in text install, which would be strange.

Created attachment 401231 [details]
Attached traceback automatically from anaconda.

Ales, you've got a patch that looks like it's going to fix this problem so I am going to assign the bug to you.

(In reply to comment #21)
> 1) if we can figure out a way to have sys.setdefaultencoding('utf8') called
> before anaconda starts we're golden.

Hm, shouldn't it be sufficient to do "import sys; sys.setdefaultencoding('utf8')" right at the top of anaconda?

Nils,

It's not that simple, unfortunately, from the setdefaultencoding documentation:
This function is only intended to be used by the site module implementation and, where needed, by sitecustomize. Once used by the site module, it is removed from the sys module’s namespace.

I have a patch that should achieve what we want, it's waiting here:
https://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00284.html

Since it could have side effects we are talking to the python maintainers to give us a blessing.

Ales

Created attachment 401697 [details]
Attached traceback automatically from anaconda.

(In reply to comment #25)
> It's not that simple, unfortunately, from the setdefaultencoding documentation:
> This function is only intended to be used by the site module implementation
> and, where needed, by sitecustomize. Once used by the site module, it is
> removed from the sys module’s namespace.

I'm puzzled about how it works with gtk then...

For F13, Fixed by e5b1f8c2eda67299a6abe1fc39a9756d3284b987.
For rhel6 please see Bug 575090.

Nils,

they have a hack in place that overrides the inmutable python variable: https://bugzilla.gnome.org/show_bug.cgi?id=132040.

We just did something superficially cleaner and not as sneaky.

Ales

(In reply to comment #29)
> Nils,
> 
> they have a hack in place that overrides the inmutable python variable:
> https://bugzilla.gnome.org/show_bug.cgi?id=132040.

Yuck.
 
> We just did something superficially cleaner and not as sneaky.

I don't get it: There must be something cleaner to fix this, at least from the scdate angle. Would it using unicode vars instead of strs help here?

I found that creating ZoneTab objects without importing gtk gives similar tracebacks. Since I only ever used this in a gtk context, I never saw these problems by myself since it made unicode conversions from utf-8 magically work. If I change the following in zonetab.py, it works without using sys.setdefaultencoding() -- I tried it with de_DE.UTF-8 and fr_FR.UTF-8:

diff --git a/src/scdate/core/zonetab.py b/src/scdate/core/zonetab.py
index 1128bd7..4d7d994 100644
--- a/src/scdate/core/zonetab.py
+++ b/src/scdate/core/zonetab.py
@@ -29,7 +29,7 @@ import locale
 import warnings
 
 from gettext import ldgettext
-gettext = lambda x: ldgettext("system-config-date", x)
+ugettext = lambda x: unicode(ldgettext("system-config-date", x), "utf-8")
 
 __all__ = ("ZoneTabEntry", "ZoneTab")
 
@@ -56,7 +56,7 @@ class ZoneTabEntry(object):
             return
 
         # time zone msgid and msgstr have underscores instead of spaces
-        translated = gettext(self._tz.replace(" ", "_")).replace("_", " ")
+        translated = ugettext(self._tz.replace(" ", "_")).replace("_", " ")
 
         (lang, coding) = locale.getlocale()
         if lang is None:

Do you think I should rather apply this to s-c-date rather than you doing nasty things in anaconda?

Yes,

having the strings in unicode from the start is a fix too and you should commit this patch to s-c-date.

To me it made sense to have anaconda start with the same default encoding every time, no matter whether it's running in text or gui, to prevent this kind of bugs. Chris, what is your opinion, should we keep the sitecustomize.py patch?

Ales

(In reply to comment #32)
> having the strings in unicode from the start is a fix too and you should commit
> this patch to s-c-date.

already committed to git, will be in the next version

> To me it made sense to have anaconda start with the same default encoding every
> time, no matter whether it's running in text or gui, to prevent this kind of
> bugs. Chris, what is your opinion, should we keep the sitecustomize.py patch?

Chris mentioned to me on IRC yesterday that he would like to keep it since you had more problems similar to this with other "3rd party" software. Perhaps you could compile a list of affected components and ping their respective maintainers? They should fix their code as well to work without importing gtk and its side-effects.

Thanks for your efforts in this.

We've hit this problem in many places throughout anaconda, most notably dealing with yum and rpm, so I am fine with us keeping the patch in anaconda to prevent other problems from showing up in anaconda too.

system-config-date-1.9.55-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/system-config-date-1.9.55-1.fc13

anaconda-13.36-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/anaconda-13.36-1.fc13

anaconda-13.36-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.36-1.fc13

Hey, folks - can people who ran into this bug please re-test with F13 Beta TC1 - http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.TC1/ ? It should be fixed there, as that includes anaconda 13.36. Thanks!

I tested TC1 here. With the DVD, doing a text mode install, I was able to successfully complete an installation selecting German as the language.

I'm not going to close this as I didn't see the initial issue so I can't be 100% sure I'm following the same method as the reporters, but it seems like a good result.

Seems to me like it has been solved with TC1.

Even there is another problem with font. Unicode (national) characters are brighter than normal characters (filled as bug #576845).

Thanks, Milan - closing. If anyone still sees the bug in TC1, reopen (if you can) or post a comment and I'll reopen.

Created attachment 403441 [details]
Attached traceback automatically from anaconda.

Created attachment 404951 [details]
Attached traceback automatically from anaconda.

Created attachment 405812 [details]
Attached traceback automatically from anaconda.

for those who've hit this bug (Razvan, Terje, ultima.ratio.regum) - as you can see, it's fixed in later versions. If you pick up Fedora 13 Beta (which will be out shortly), it'll work fine there. Sorry for the inconvenience.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I tried a RC Beta release and that worked fine, thanks.

system-config-date-1.9.56-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Created attachment 409118 [details]
Attached traceback automatically from anaconda.

Comment #48 was from the boot.iso.

Created attachment 412625 [details]
Attached traceback automatically from anaconda.

*** Bug 538328 has been marked as a duplicate of this bug. ***