Created attachment 91240 [details]
screenshot of the brokenness

this happens regardless of what I set TERM to

hp gave me the reason for this problem, I suppose you can close the bug, but
please look at my answer

----------------------------------------------------------------------------
> You have to match the encoding of mc to the encoding of 
> your terminal. The encoding of mc comes from the locale; for 
> example, LANG=en_US.UTF-8 gives UTF-8 encoding, 
> LANG=en_US.ISO-8859-1 gives Latin-1. 7.3 terminal will be expecting
> Latin-1 by default. RHL 9 gnome-terminal has a menu Terminal->Character Coding
> which can be used to change encoding to match remote systems.

Indeed, thanks for pointing that out, I missed that change (and boy, did I
look for it. Can this be added someone, like in the release notes next time)

I know why you are making this change, but honestly knowing that it breaks
remote connections in a non obvious way, I question the wiseness of this new
default.
It also breaks any other terminal by default (like xterm/Eterm/whatever),       
doesn't it?

> This can't be done automatically because the ssh and telnet protocols do
> not include encoding negotiation. A screwup in those protocols, so 

That's true

> the only solution is to manually set your encodings properly.

Other possible fixes would have been:
1) auto-set lang to en_US.ISO-8859-1 for remote connections
2) have gnome-terminal set a new TERM type (which gets passed by
   telnet/ssh/rlogin) and set lang to en_US.UTF-8 only if this new TERM
   type is detected (like xterm-utf8)
----------------------------------------------------------------------------

I don't often use X and therefore am not particularly familiar with the ins and
outs of encodings. I use the Win32 client Putty to access my Red Hat Linux host
via SSH. When I run the setup utility, each of its configuration programs works,
except for timeconfig, which fails in the way described by Marc. Putty provides
configuration options for the encoding type. And, fiddling with them alters the
setup program's menu in some interesting ways. But, no setting I've found coaxes
timeconfig into working over the SSH connection. So, it seems that I must travel
to the NOC to reset the timezone on an errantly configured host. 

Perhaps I'm missing the obvious. But, I can't see how to change the encoding in
a way that works around this problem. And, I'm puzzled why the problem affects
only timeconfig, not authconfig and timeconfig's other siblings.

Bill, when I ssh from an xterm on a 7.2 box into a 9 box, all the text utilities
look messed up to me.  I don't think that there's anything different about
timeconfig.

The best thing I can tell you is to follow hp's advice and prepend
'LANG=en_US.ISO-8859-1' to the command to run any of the text based tools.  That
seems to work for me.  Basically, a lot of things are going to be a mess until
everything uses UTF-8 encoding.

I dont't think that there's anything I can do in the context of timeconfig to
fix this problem.  Closing as 'wontfix'.  

Hi Brent,

Thanks for the additional info. But, I don't think your test using an xterm goes
to the heart of the issue. You point out that everything's messed up with xterm.
That's interesting. 

But, when I use Win32 putty, the only member of the setup program that fails is
timeconfig. Moreover, timeconfig can't be coaxed into working by prepending an
assignment to the LANG environment variable, as suggested. So, timeconfig
differs in some important--and unwholesome--way from the other members of the
setup program.

Make sense?

Cheers,

Ok, I've downloaded putty on my Win2k box.  I get the same behavior as if I was
on a RHL 7.2 box.  All the text mode tools look bad until I prepend
"LANG=en_US.ISO-8859-1" to whatever command I'm running.  Then things look fine.  

I'm attaching screenshots of timeconfig and authconfig to demonstrate the
behavior.  The ones that look good had "LANG=en_US.ISO-8859-1" prepended to the
command.  The ones that look bad did not.

Brent, please set the mime type of your attachements to image/png, not text/plain

Hey y'all,

Here's yet another twist. I have a second RHL 9 host. When I SSH into it by
using Putty, all the programs accessed via the setup command work okay, except
for timeconfig. The screens are a bit messy, but not so bad as to be unusable.
The line drawing characters are substituted by letters with diacritical marks
and such. That's all.

Timeconfig, on the other hand, dies. Running timeconfig directly from the
command line yields a visible stack trace showing that timeconfig is trying to
open the X display:

# timeconfig
Traceback (most recent call last):
  File "/usr/share/redhat-config-date/timeconfig.py", line 29, in ?
    from timezone_map_gui import ZoneTab
  File "/usr/share/redhat-config-date/timezone_map_gui.py", line 18, in ?
    import gtk
  File
"/usr/src/build/218821-i386/install/usr/lib/python2.2/site-packages/gtk-2.0/gtk/__init__.py",
line 43, in ?
RuntimeError: could not open display


Note that the environment variable DISPLAY is not set:

# echo $DISPLAY

# 

Has timeconfig gone GUI-only in RHL 9?

Cheers,

marc: sorry about that.  I thought bugzilla could detect file types...

Created attachment 92080 [details]
authconfig good

Created attachment 92081 [details]
authconfig bad

Created attachment 92082 [details]
timeconfig bad

Created attachment 92083 [details]
timeconfig good

Bill, that particular bug you are seeing is a dupe of bug #90185, which was
fixed in redhat-config-date-1.5.10-1 last week.

I'm going to close this bug as 'wontfix' since I don't really see a
way to fix it.  Over time, as everything moves to UTF-8 encoding, this
problem should go away.  In the meantime, prepending
"LANG=en_US.ISO-8859-1" can suffice as a workaround.