Created attachment 293597 [details]
pirut error message if you use LANG=de_DE

Created attachment 293598 [details]
pirut error message if you use LANG=de

 Ok, trying this on Fedora 8 I get:

/usr/sbin/pirut:417: GtkWarning: Failed to set text from markup due to error
parsing markup: Fehler in Zeile 1: Zeichen » « ist in einem Entitätsnamen ungültig
  gtk.main()
/usr/sbin/pirut:417: GtkWarning: Failed to set text from markup due to error
parsing markup: Fehler in Zeile 1: Zeichen » « ist am Anfang eines
Entitätsnamens ungültig; eine Entität beginnt mit dem Zeichen &; wenn das Et
keine Entität sein soll, es als & umschreiben
  gtk.main()
/usr/sbin/pirut:417: GtkWarning: Failed to set text from markup due to error
parsing markup: Fehler in Zeile 1: Zeichen »'« ist in einem Entitätsnamen ungültig
  gtk.main()

...which I assume means one of two things:

1. we have a newer gtk in Fedora 8, which doesn't have the assert problem and
we'll have to work around it in RHEL-5.2

2. The translations are different in Fedora 8 vs. RHEL-5.2 and we should copy
them over, I think this should be the same (as it's the same tarball/src.rpm)
but I want to make sure I'm not missing something.

...do you know if I can rule out #2?

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

 Looking into this a bit more, the only place that calls set_text is:


buffer.set_text(sanitizeString(desc))

..and sanitizeString() ends with:

def sanitizeString(s, translate = True):
[...]
    if type(s) != unicode:
        try:
            s = unicode(s, "utf-8")
        except UnicodeDecodeError, e:
            print >> sys.stderr, "Unable to convert %s to a unicode object: %s"
%(s, e)
            return ""
    return s

...which should ensure that "s" passes g_utf8_validate () ... more investigation
required I guess.

 Ok, not sure why the currect code doesn't work ... but I've reverted to the old
(RHEL-5.0 GA) behaviour of using utf8() from rhpl.translate. See if that fixes
it for you, pirut-1_3_28-3_el5

I tried this new package and behaviour didn't change.

More testing showed, that it doesn't seem to be a pirut issue. It seems to be a
yum issue. 

If I execute "yum show python-tools" I get the attached error messages.
While upgrading pirut, I also upgraded yum:
# rpm -qa | grep yum
yum-updatesd-0.9-2
yum-utils-1.1.10-2
yum-metadata-parser-1.1.2-2
yum-rhn-plugin-0.5.2-5.el5_1.2
yum-3.2.8-5

Last lines of output of pirut in comment #1 and attached output, seems to be the
same.
LANG=C yum show python-tools does not crash
LANG=de_DE yum show python-tools does crash

Created attachment 293883 [details]
error message of LANG=de_DE yum info python-tools

 Damn I remember fixing this for Fedora, python's gettext doesn't like .po files
formatted in a certain way.
 We can either re-format the .po files, or include the python gettext fix
(probably hard, due to it not being updated so far) ... *sigh*.

 Ok, I've reverted the gettext code to rhpl.translate varient, which should
resolve this without us having to alter python.
 Please try: pirut-1.3.28-4.el5.src.rpm

It is still not working, but the error message changed:
# pirut 
Loading "rhnplugin" plugin
Component: pirut
Summary: TB9ce3a230 __init__.py:866:sanitizeString:NameError: global name
'textdomain' is not defined

Traceback (most recent call last):
  File "/usr/sbin/pirut", line 121, in _pageSwitch
    self.pageMap[num]()
  File "/usr/sbin/pirut", line 305, in _showListReal
    plist.addPackage(po, t)
  File "/usr/lib/python2.4/site-packages/pirut/PackageList.py", line 142, in
addPackage
    self.pkgStore.append([po, pix in installedpix, pix,
  File "/usr/lib/python2.4/site-packages/pirut/PackageList.py", line 67, in
listEntryString
    desc = "<b>%s</b> - %s" %(po, pirut.sanitizeString(desc))
  File "/usr/lib/python2.4/site-packages/pirut/__init__.py", line 866, in
sanitizeString
    textdomain(d)
NameError: global name 'textdomain' is not defined

Local variables in innermost frame:
i18ndomains: ['redhat-dist']
s: Umwandlung von Text und anderen Dateitypen in PostScript(TM).
translate: True
d: redhat-dist

Pirut now also fails if I try this:
LANG=C pirut
With the same error message (but in english this time)

 Of course a missing import makes it in to what I commit ... should be fixed in
pirut-1.3.28-5.el5.src.rpm

 Thanks for the quick testing.

Now the bug in comment #11 is gone.
But I still see the original bug. :-(

 Wait you get the problem in comment#8 or the very first one in comment#0 ?

Created attachment 294107 [details]
current python backtrace

since the backtrace looks slightly different with the current pirut package, I
added the new one.
Packages:
yum-updatesd-0.9-2
yum-utils-1.1.10-2
yum-metadata-parser-1.1.2-2
yum-rhn-plugin-0.5.2-5.el5_1.2
yum-3.2.8-5
pirut-1.3.28-5.el5

Created attachment 294112 [details]
Fix for python gettext split problem

 Ok, it's the comment#8 problem ... It looks like rhpl.translate is also goling
through the python gettext code ... weird, I don't understand why that's
triggering with the new pirut and not the old one.

 Anyway it looks like we'll have to fix python, can you try applying this to
your installed python (just apply it to the installed file). This should fix
the python problem (it does in Fedora) but I want to make sure there isn't
anything else.

I applied the patch from comment #16 and it fixes all the specified problems.

 Ok, could you do one last test. Could you test downgrading your pirut/yum to
the RHEL-5.0 GA versions (without the above python fix) and see if it has the
same problems with the .po data.
 I assume it will, which will go a long way towards making the python errata
easy to propose.

 TiA.

I downgraded yum, pirut and checked python. With this old packages, I don't get
the error I reported:

yum-rhn-plugin-0.4.3-1.el5
yum-updatesd-3.0.1-5.el5
yum-metadata-parser-1.0-8.fc6
yum-utils-1.0.4-3.el5
yum-3.0.1-5.el5
pirut-1.2.10-1.el5
python-2.4.3-19.el5

 Ok, not the answer I was expecting, but I see now ... the older version wasn't
loading "de" (like /usr/share/locale/de/LC_MESSAGES/redhat-dist.mo) when in
"de_DE", I've created a new package which might work around it (pirut-1.3.28-6.el5).
 Also can you confirm/deny whether "LANG=de pirut" works with the GA version?

LANG=de pirut on RHEL5 GA switches back to LANG=C:
# LANG=de pirut

(pirut:7303): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
Loading "installonlyn" plugin
Loading "rhnplugin" plugin

I will upgrade to newest pirut and report back soon.

This looks good. I upgraded to the newest pirut package and
LANG=de_DE pirut
doesn't crash!

# rpm -qa | grep -e yum -e pirut -e iniparse
yum-updatesd-0.9-2
python-iniparse-0.2.3-4.el5
yum-utils-1.1.10-2
yum-3.2.8-5
yum-rhn-plugin-0.5.3-1.el5
pirut-1.3.28-6.el5
yum-metadata-parser-1.1.2-2

Additional info:
# LANG=de pirut

(pirut:8372): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
Loading "rhnplugin" plugin

 Ok, thank you again for all the testing. The latest fix should go into the
errata tonight.

Created attachment 295493 [details]
Output of LANG=de_DE yum info lftp

I have to correct myself. I looked again into the example from comment #8:
LANG=de_DE yum info <package name> fails

packages installed:
# rpm -qa | grep -e yum -e inipar
yum-updatesd-0.9-2
python-iniparse-0.2.3-4.el5
yum-utils-1.1.10-2
yum-3.2.8-5
yum-rhn-plugin-0.5.3-1.el5
yum-metadata-parser-1.1.2-2

I appologize for my bad testing.

 Ahh, yum needs a workaround too. *me hopes this is it*.
 I built: yum-3.2.8-7.el5 which should have a workaround in it.

 It's just:

-                    t = gettext.dgettext(d, s)
+                    try:
+                        t = gettext.dgettext(d, s)
+                    except AttributeError: # Horrible hack for python bug
+                       t = s

...in usr/share/yum-cli/output.py

With this latest package, yum does not crash any more.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0388.html