[25705] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: gnome-panel clock not fully functional

daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jun 17 16:30:05 2004

From: Greg Hudson <ghudson@mit.edu>
To: "Adam D'Amico" <adamico@mit.edu>
In-Reply-To: <200406171523.i5HFNfOl007985@melbourne-city-street.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1087504042.8231.11.camel@equal-rites.mit.edu>
Mime-Version: 1.0
Date: Thu, 17 Jun 2004 16:27:22 -0400
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu

On Thu, 2004-06-17 at 11:23, Adam D'Amico wrote:
> Looking at versions, it appears that all the machines that exhibit
> this behavior went from 9.2 straight to 9.3.6, while machines that
> don't took some earlier version of 9.3.  This is true for Kevin's
> tests as well.

Ah, excellent research, thanks.

The problem lies with the file /usr/athena/lib/charset.aliases.  Four
MIT-* packages claim ownership of this file, and one of them
(MIT-gnome-vfs) writes a very truncated version of it.  If a machine
upgraded to 9.3.4 or later directly, it gets the MIT-gnome-vfs version;
if a machine upgraded to 9.3.3 and then to a later version, it gets the
MIT-libiconv version.

If you have the truncated file, you don't have a mapping from "646" (the
default charset on Solaris) to "ASCII", which leads to an inability to
translate from the default charset to UTF-8, which leads to the clock
lossage.

In the next patch release, we will add a hack to the build script such
that only MIT-libiconv owns the file, which should settle the issue.


home help back first fref pref prev next nref lref last post