Bug 15887

Something must be done with this bug. I've checked its presense in Arch Linux, Mandriva 2009 Powerpack using XMMS and WMII.

A patch that was generated against/could be applied to the X.Org upstream 
sources instead of FreeBSD's build system and pre-existing patches would 
help get something done sooner.

Created attachment 23765 [details] [review]
debian patch for ru_RU.UTF-8

Debian's carrying the attached patch since 6.9.0.  I guess I could push that upstream.  Original patch author is Eugene Konev <ejka@imfi.kspu.ru> (see debian bug#330144).

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

Looking at Debian’s patch, ru_RU.UTF-8/XI18N_OBJS is based on pt_BR.UTF-8/XI18N_OBJS, so that should be OK, even though XIM and XOM lines differ from en_US.UTF-8/XI18N_OBJS.

It may be the case that one or the other needs to be updated, but it looks like a determination will require looking through XFree86’s repo and perhaps the old monolithic releases to find the history of pt_BR’s and en_US’s versions....

The ru_RU.UTF-8/XLC_LOCALE.pre seems to be OK.

ru_RU.UTF-8/Compose.pre, OTOH, is not.  It looks like:

,----
| include "/usr/share/X11/locale/en_US.UTF-8/Compose"
`----

First, IIRC, the support for include commands in the installed Compose files is part of another patch Debian adds.  Also it ignores --prefix, rather hardcoding the installed location of the locale db.

Since the .pre files are processed through the C preprocessor, it should be:

#include "../en_US.UTF-8/Compose.pre"

Otherwise, it looks OK.

Thanks for looking over the patch!

> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> ru_RU.UTF-8/Compose.pre, OTOH, is not.  It looks like:
> 
> ,----
> | include "/usr/share/X11/locale/en_US.UTF-8/Compose"
> `----
> 
> First, IIRC, the support for include commands in the installed Compose files is
> part of another patch Debian adds.

That's not true afaik.  Support for include in compose files was added
back in xfree86.  See commit c6349f43193b74a3c09945f3093a871b0157ba47,
in modules/im/ximcp/imLcPrs.c:parseline().

>   Also it ignores --prefix, rather hardcoding
> the installed location of the locale db.
> 
ack

> Since the .pre files are processed through the C preprocessor, it should be:
> 
> #include "../en_US.UTF-8/Compose.pre"
> 
> Otherwise, it looks OK.
> 
I'll make these changes and attach an updated patch.

> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> Looking at Debian’s patch, ru_RU.UTF-8/XI18N_OBJS is based on
> pt_BR.UTF-8/XI18N_OBJS, so that should be OK, even though XIM and XOM lines
> differ from en_US.UTF-8/XI18N_OBJS.
> 
> It may be the case that one or the other needs to be updated, but it looks like
> a determination will require looking through XFree86’s repo and perhaps the
> old monolithic releases to find the history of pt_BR’s and en_US’s
> versions....

xfree86's version of nls/XI18N_OBJS/en_US.UTF-8 looks similar to our
pt_BR.UTF-8, and hasn't changed in at least 7 years.

Also, it seems that _SwitchOpenIM and _XimpLocalOpenIM don't actually
exist anywhere.  The files still referencing xiiimp should probably be
updated, as that doesn't seem to exist.  This seems to be true for a
bunch of other modules (ximp40, ximlocal and xomLTRTTB).  Sigh.

> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> Since the .pre files are processed through the C preprocessor, it should be:
> 
> #include "../en_US.UTF-8/Compose.pre"

this doesn't work when builddir != srcdir, unfortunately.

>> #include "../en_US.UTF-8/Compose.pre"

> this doesn't work when builddir != srcdir, unfortunately.

Since I was wrong about the provenence of include (as opposed to
#include), then the only change the proposed patch needs there is
to honour $X11_LOCALEDATADIR.  I suspect that that will require
these changes to cpprules.in:

diff --git a/cpprules.in b/cpprules.in
index 12964fa..16ede7e 100644
--- a/cpprules.in
+++ b/cpprules.in
@@ -7,8 +7,9 @@ SED = sed
 SUFFIXES = .pre
 
 WCHAR32_FLAGS = -DWCHAR32=@WCHAR32@
+LOCALEDATADIR_FLAGS = -DX11_LOCALEDATADIR=\"@X11_LOCALEDATADIR@\"
 
-CPP_FILES_FLAGS = $(WCHAR32_FLAGS)
+CPP_FILES_FLAGS = $(WCHAR32_FLAGS) $(LOCALEDATADIR_FLAGS)
 
 # Translate XCOMM into pound sign with sed, rather than passing -DXCOMM=XCOMM
 # to cpp, because that trick does not work on all ANSI C preprocessors.

and then using:

include X11_LOCALEDATADIR"/en_US.UTF-8/Compose"

for the Compose.pre file.

A quick test shows that the above changes create a Compose file which
looks like:

include "/usr/share/X11/locale""/en_US.UTF-8/Compose"

after a ./configure --prefix=/usr && cd ... && make Compose

so cpprules will also need some more sed to remove the "".  (I don't see
any portable way to get cpp to expand the macro inside a " string....)

> --- Comment #9 from James Cloos <cloos@jhcloos.com>  2009-03-17 03:26:01 PST ---
> so cpprules will also need some more sed to remove the "".  (I don't see
> any portable way to get cpp to expand the macro inside a " string....)
> 
or since we run sed on the Compose file anyway, we could do the
substitution then.
e.g. adding
 -e 's/X11_LOCALEDATADIR/$(X11_LOCALEDATADIR)/g'
to CPP_SED_MAGIC in cpprules.in and
include "X11_LOCALEDATADIR/en_US.UTF-8/Compose"
to nls/ru_RU.UTF-8/Compose.pre.  that seems simpler to me, what do you
think?

(In reply to comment #10)
> or since we run sed on the Compose file anyway, we could do the
> substitution then.

I pushed the patch with that change.  Thanks again for the review James.

commit e3198b55dc16ec57346cc28aa8d34165ce8cde96
Author: Julien Cristau <jcristau@debian.org>
Date:   Fri Mar 13 13:52:33 2009 +0100

    Add a ru_RU.UTF-8 locale
    
    Based on patch by Eugene Konev <ejka@imfi.kspu.ru> for X.Org 6.9.0.
    
    Debian bug#330144 <http://bugs.debian.org/330144>
    X.Org bug#15887 <http://bugs.freedesktop.org/show_bug.cgi?id=15887>