Bug 84247 - XKeepsFailing depends on gettext
XKeepsFailing depends on gettext
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdm (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Mike McLean
: Triaged
Depends On:
Blocks: 79579 CambridgeTarget
  Show dependency treegraph
 
Reported: 2003-02-13 14:04 EST by Miloslav Trmac
Modified: 2007-04-18 12:51 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-04 07:41:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miloslav Trmac 2003-02-13 14:04:30 EST
Steps to Reproduce:
0.rpm -e gettext
1.Be an total idiot
2.Set your mouse type to "sun"
3.Try to start X again
    
Description of problem:
After a few attempts, XKeepsFailing kicks in. It doesn't
run redhat-config-xfree86, although it seems to be supposed to.
Anyway, then it displays a dialog (using gdialog), that is completely
empty (1) except for something unreadable at the bottom, which is
probably supposed to be a button. (2)
I can navigate through a few dialogs, but I don't see any text
and the buttons are unreadable.

1) Looking at the script, it invokes 'gettext -s', but gdm doesn't
require gettext. The scripts seems to attempt to avoid bash-isms,
but here a bashism would be useful the $" " way of getting
translations. Anyway, the current version attempts to run gettext
and gets empty strings in return.

So either gettext should be required, or the script needs fixing.

2) runnig gdialog when logged in in text mode produces correctly
looking buttons though.
A theory (not checked at all), is that when nobody is logged in
on a VT, it is in a "default" state which doesn't have UTF-8
support enabled, the support is enabled after logging in.
This can be verified by setting your keyboard via e.g.
loadkeys -u cz-lat2.
Then you should be able to produce &ecaron, &scaron, &ccaron by
pressing AltGr-{2,3,4} when logged in a VT. When not logged in,
these keys produce UTF-8 garbage.
So, possibly the dialogs are run on a VT that has UTF-8 disabled.

Version-Release number of selected component (if applicable):
gdm-2.4.1.1-1
Comment 1 Philip Long 2003-02-17 12:08:27 EST
After changing screens from a CRT (1280x1024) to an SGI 1600SW (1600x1024)
(hooray for ebay) I got something simialr - 

the gdm screen was blank,  but the mouse pointer was there.  I didn't see any
garbage at the bottom, though.

I changed resoultions to 800x600 and progressed bac to 1600x1024 and the problem
seem to have resolved itself.
Comment 2 Miloslav Trmac 2003-02-17 12:32:20 EST
Philip: if you saw a (graphic) mouse pointer and nothing more, it is
a different problem.
I was talking about an empty dialog, i.e. a cyan rectangle with some
"garbage buttons" at the bottom. And in text mode.
Comment 3 Havoc Pennington 2003-02-18 14:36:22 EST
Probably some UTF-8 mess
Comment 4 Miloslav Trmac 2003-08-07 17:24:20 EDT
In severn, the dialogs are quite readable. None of dialog, gdialog and whiptail
are able to display perfect dialog windows in UTF-8, but that's for separate
bug reports.

Still unfixed is the missing dependency of gdm on /bin/gettext.
Comment 5 George Lebl 2003-08-07 18:09:10 EDT
In upstream 2.4.1.5 the dependency is fixed by just not using gettext if it
isn't found.  In the devel version I have a separate utility to do translations
rather then rely on gettext.  This can be fixed in older versions by just taking
the XKeepsFailing script from the 2.4.1.5 version.
Comment 6 Alexander Larsson 2003-09-04 07:41:42 EDT
We upgraded to the gnome 2.4 gdm, so I assume (since george said so) that this
is fixed now.

Note You need to log in before you can comment on or make changes to this bug.