Bug 467488 - Add package compat-locales-sap to the RHEL5 SAP Supplementary channel
Add package compat-locales-sap to the RHEL5 SAP Supplementary channel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: distribution (Show other bugs)
5.4
All Linux
urgent Severity high
: rc
: 5.4
Assigned To: Jens Petersen
desktop-bugs@redhat.com
NwCmp: sap-locale
: FutureFeature, OtherQA
: 249677 249679 249682 (view as bug list)
Depends On: 488915
Blocks: 495526 241675 460679 508595 512803
  Show dependency treegraph
 
Reported: 2008-10-17 14:25 EDT by Daniel Riek
Modified: 2018-02-27 07:13 EST (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 508595 512803 (view as bug list)
Environment:
Last Closed: 2009-08-04 12:36:19 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)
SAP notes including saplocales details (25.50 KB, application/octet-stream)
2009-02-06 09:43 EST, Michael Waite
no flags Details
SAP Application Notes for Locales (25.50 KB, text/plain)
2009-02-06 09:57 EST, Russell Doty
no flags Details
Czech Language Locale for Czech with SAP sorting order (89.28 KB, text/plain)
2009-05-14 00:31 EDT, Pravin Satpute
no flags Details
Slovak Language Locale for Slovak with SAP sorting order (5.50 KB, text/plain)
2009-05-14 00:35 EDT, Pravin Satpute
no flags Details
result files for problematic locales (11.55 KB, application/x-bzip2)
2009-06-15 14:44 EDT, Hannes Kuehnemund
no flags Details
nls_check for linuxx86_64 (449.11 KB, application/x-bzip2)
2009-06-17 05:22 EDT, Hannes Kuehnemund
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:1194 normal SHIPPED_LIVE Compatibility locales for SAP 2009-08-04 12:36:16 EDT

  None (edit)
Description Daniel Riek 2008-10-17 14:25:46 EDT
Add a package with the legacy locales needed for SAP compatibility to the Supplementary channel and disk.

See bug 241675 for the details.
Comment 2 Michael Waite 2009-01-16 15:55:48 EST
What can I do to move this along please. SAP customers would like to have this resolved.
Comment 3 Michael Waite 2009-01-19 08:34:52 EST
Having correct sorting locales is really important to all of SAP's customers
who haven't yet switched to Unicode (probably > 85% of all SAP
customers).

Hannes wrote a blog about this problem:
https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10650

Here is an excerpt of his blog:
<SNIP>
: One operating system which ignores the special characters is Linux.
Novell does provide adapted locales starting with SLES10 SP2. 
: The sap-locale package contains a modified de_DE.iso88591 (named
de_DE.iso88591@SAP_HP) locale which sorts the special characters 
: based on the HP-UX sorting. Other locales are currently not part of
the package and must be requested through the standard 
: Novell support channels. The same counts for Red Hat Enterprise Linux.
With Red Hat, customers have to book this service from 
: Red Hat consulting. The SAP note describing the procedure for both
distributors is 1069443. 
<END SNIP>

I would like to help with this effort and would like to add the locales for HPUX, Solaris and AIX as this will make RHEL a more seamless migration from those platforms than other vendors. How can I help?
Comment 14 Michael Waite 2009-02-04 08:18:22 EST
I am not an expert, I am hoping that Nils can chime in seeing as he has the most in-depth SAP knowledge.
Comment 15 Michael Waite 2009-02-04 13:27:05 EST
I am not sure I understand the details in "Comment #13", I'll defer to those folks on this thread that are much smarter than I. 
What I do understand is that there is a business problem in that Red Hat does not have what the competition has and this is making it more difficult for our sales teams to close deals. 

The general populace does not see, nor have an appetite for the details in the "why". What they perceive is that Red Hat does not work as well for SAP customers as the other operating systems do.

------Mike
Comment 20 Michael Waite 2009-02-05 11:51:30 EST
There is some comprehensive documentation on this issue and the relationship to glibc here:

https://service.sap.com/sap/support/notes/171356

They have attached all of the locales packages at the bottom of the thread as well

After each "glibc" RPM update, you must import "saplocales" again (see Note 516716)
Comment 27 Hannes Kuehnemund 2009-02-11 09:22:40 EST
Hi,

let me introduce myself. My name is Hannes Kuehnemund and I'm member of the SAP LinuxLab. I'm the maintainer of the saplocales rpm. The purpose of this package is to enable customers to use SAP blended (legacy) locales. 

Please note, that we do not want Red Hat to ship our legacy locales.

Let me give you some more background on the topic. In the last 12 years the saplocales package content was extended with modified glibc locales. The reason why we had to modify selected glibc locales is, that a certain set of Linux glibc locales differs with their counterparts from UNIX or Windows. In hererogenous environments where you distribute SAP application servers between UNIX and Linux you have to ensure that character conversion, character maps and character sorting is the same on all underlying platforms. 

Up to last year, the saplocales package came with these additional adapted glibc locales:

* tr_TR.ISO-8859-9
* ko_KR.KSC5601
* lt_LT.ISO-8859-4
* lv_LV.ISO-8859-4
* et_EE.ISO-8859-4
* de_DE.ISO-8859-1
* cs_CZ.ISO-8859-2
* ja_JP.SJIS (w/o shift state)

We know, that the Linux glibc locales are correct according to the ISO norm. But as all other Unices and Windows have a different view on this topic we need a solution. 

What we do not want is that Red Hat changes the standard locales delivered through glibc.

What we'd ask you is, create an additional package which delivers the above mentioned locales, because we had to remove these locales from the saplocales package (legal requirements). These locales should be compatible to their counterparts on other operating systems. As these locales should not interfear with the already installed locales, we'd suggest the following naming convention:

* tr_TR.ISO-8859-9@SAP
* ko_KR.euckr@SAP
* lt_LT.ISO-8859-4@SAP
* lv_LV.ISO-8859-4@SAP
* et_EE.ISO-8859-4@SAP
* de_DE.ISO-8859-1@SAP
* cs_CZ.ISO-8859-2@SAP
* ja_JP.SJIS@SAP (w/o shift state)

Another advantage of this convention is the compatibility with the package that comes from Novell.

The changes in these locales are manifold. The Turkish locale needs a different conversion for x69, x49, xdd and xfd. The Czech locale should have a sorting, that numbers are sorted before the characters (which is against ČSN 01 0181, but allows human readable Hex dumps). The Baltic locales should use the ISO-8859-4 (Latin-4) instead of ISO-8859-13 (Latin-7). The Japanese locale is a little bit tricky, the background might be too detailed for this BZ. 

We've sent you a document with the behavior of the UNIX locales and what has to be done to adept the Linux glibc locales accordingly. If you need this paper again, or if you need any other information, please let me know.

Apart from that, providing locale compatibility with other operating systems is a neet thing to make marketing with :-)
Comment 28 Russell Doty 2009-02-11 09:56:21 EST
Hannes,

Please attach the Unix locales document to this BZ.

Also, can you provide some more information on the "legal requirements: that have caused you to remove these locales from the saplocales package?
Comment 29 Hannes Kuehnemund 2009-02-12 09:59:17 EST
Russ,

the requirement comes form our legal department. They don't allow us to provide open source on behalf of SAP. As the adepted glibc locales are open source, we cannot deliver them. 

Regarding the document, it has to be revised to reflect the current situation. I attach it soon.
Comment 30 Michael Waite 2009-02-13 11:51:56 EST
Hi Jens,
Do we have everything we need now to move forward on this issue?
Comment 37 Michael Waite 2009-02-17 13:40:26 EST
Nils and/or SAP folk,
Do you know what testing has been done with the saplocales packages for rhel5? There seems to be some confusion here as to the readiness of the software for inclusion into the RHEL5 distribution.

Thanks
------Mike
Comment 38 Hannes Kuehnemund 2009-02-17 13:52:20 EST
I didn't get anything I could test, Sorry...
Comment 39 Russell Doty 2009-02-17 15:46:56 EST
Hannes,

We've run into several problems attempting to build the saplocales package on RHEL 5. Who should we work with at SAP to resolve these - you or someone else?

* Failed to build due to strict type checking in gcc.

* After patching to get it to build, it segfaults when doing iconv.
Comment 40 Hannes Kuehnemund 2009-02-18 04:38:57 EST
I'm happy to assist on this issue. We did not face problems when building the package testwise on RHEL5.

How can I help?
Comment 41 Michael Waite 2009-02-18 15:25:40 EST
This was originally Bug 241675 opened back in May 2005
Then this ticket 467488 was opened in October 2008
I would like very much to bring this to closure soon so our customers will have the support that they need.
My questions are:

Yu Shao, your name is listed as the owner of this feature request, can you please help move this along?

Where is the software now?
Who owns it?
What to we need to test it?
Comment 48 Michael Waite 2009-02-19 15:34:24 EST
Russ,
I would like to be on the call please.
Comment 57 Ulrich Drepper 2009-03-02 10:48:56 EST
Created attachment 333751 [details]
missing sysdep.h file

Missing sysdep.h file from the patch.

My fault, the tools didn't pick up this change because it's a new file.
Comment 70 Jens Petersen 2009-03-06 02:18:07 EST
Ok so here is a newer package with all locale enabled and some more notes in the package about them:

http://people.redhat.com/petersen/.sap/saplocales-2.2.5-3.el5.src.rpm
http://people.redhat.com/petersen/.sap/saplocales.spec

is this what we want?
Comment 74 Russell Doty 2009-03-13 09:37:16 EDT
SAP - a package containing the SAP Locales is available; see comment #70.

Please test this package and make sure it meets your needs.
Comment 75 Hannes Kuehnemund 2009-03-16 07:16:52 EDT
Thanks a lot for providing the package. It somehow happened that we have a misunderstanding here. I talked to Russ and we agreed that I provide some more information. Please use comment #27 as reference.



There is a package at SAP, called saplocales-<glibcvers>.rpm. The intention of having this package back in 1996 was to provide SAP blended code pages to customers. The official SAP documentation says:



--------------------------------------------------

There are many code points that are unused in standard, double-byte code pages, and in order to enhance the capability of a single code-page R/3 system, SAP offers double-byte blended code pages, which contain characters from two or more standard code pages. For example the SAP blended code page Asian UnificationK contains all of the 7 bit ASCII characters, all of the Korean characters in KSC5601 as well as a large portion of the SJIS characters (single-byte katakana, as well as certain other characters are not included.



Asian UnificationK therefore provides all of the characters needed for English, Korean, and Japanese with a single code page.

--------------------------------------------------



Between 1996 and today the SAP LinuxLab found several Linux locales which don't act identical to other Unix or Windows locales. Some of them have a different sorting, others have different toupper/tolower counterparts and others have a different code set. For SAP supporting heterogeneous environments, the locales on every operating system in the landscape has to have the same locales in place. Imaging different toupper/tolower behavior when storing data in the database. You write on a RHEL AppServer into the database but the data cannot be read correctly using AIX or Windows application server. 



To help the customer very quickly, the saplocales package was extended with modified glibc locales. Our intension from the very early beginning was to get these changes back to the distributor, but this never worked out very well. However, I see that we can make this happen in the very near future.	



What do we offer you: We give you the information, which Linux locales are different to their Unix counterparts. You then create a separate package called sap-locale (or anything else, except saplocales, which is still delivered by SAP) which contains the adapted glibc locales. This enables you to have locale compatibility between RHEL and the other operating systems for SAP. We suggest the following names for these locales:



* tr_TR.ISO-8859-9@SAP

* ko_KR.euckr@SAP

* lt_LT.ISO-8859-4@SAP

* lv_LV.ISO-8859-4@SAP

* et_EE.ISO-8859-4@SAP

* de_DE.ISO-8859-1@SAP

* cs_CZ.ISO-8859-2@SAP

* ja_JP.SJIS@SAP (w/o shift state)



We gave you the saplocales package as base information which changes need to be made for the glibc locales. We did not expect that you rebuild it, removing the glibc locales and leave the blended code pages inside. Vice Versa would have been nice ;-)



My question now is, do you have all the information about the changes in your new package (I suggest sap-locale package as name) or are we still missing something? If we miss something, please get in touch with me, either via this bugzilla or preferably via telephone call.

I think Russ can setup a call if needed
Comment 76 Jens Petersen 2009-03-16 20:03:21 EDT
(In reply to comment #75)

I don't understand very well...

> * tr_TR.ISO-8859-9@SAP

Is this the current tr_TR.ISO-8859-9 in saplocales-2.2.5-3.el5.src.rpm?

> * ko_KR.euckr@SAP

Is this ko_KR.KSC5601 in saplocales-2.2.5-3.el5.src.rpm?

> * lt_LT.ISO-8859-4@SAP
> * lv_LV.ISO-8859-4@SAP
> * et_EE.ISO-8859-4@SAP
> * de_DE.ISO-8859-1@SAP
> * cs_CZ.ISO-8859-2@SAP

Where are these defined?

> * ja_JP.SJIS@SAP (w/o shift state)

Is this ja_JP.SJIS in saplocales-2.2.5-3.el5.src.rpm?

> We did not expect that you rebuild it,

Sorry but the package had to be reworked since it was not really following our packaging standards.

> removing the glibc locales and leave the blended code pages inside.
> Vice Versa would have been nice ;-)

Could you please be explicit about what should be in the package and what not?

> My question now is, do you have all the information about the changes in your
> new package (I suggest sap-locale package as name) or are we still missing
> something?

Ok, we can rename the package to sap-locale (or sap-locales?).

What else am I missing?
Comment 77 Hannes Kuehnemund 2009-03-17 03:32:59 EDT
Russ, can you set up a call please?
Comment 79 Jens Petersen 2009-03-18 04:37:21 EDT
Thank you Hannes for explaining your requirements on the phone.

It seems there was a misunderstanding inside Red Hat that the old saplocales was what was wanted included in the SAP channel.

Basically what SAP actually wants is exactly explained in comment 27, comment 75 and the original bug 241675.

I will try to summarise briefly here so that Hannes can confirm we are on the right track now hopefully going forward:

The following locales are needed in the new sap-locale package:

 * tr_TR.ISO-8859-9@SAP

This is basically just the old Turkish locale in the old saplocales package.

 * ko_KR.euckr@SAP

This is an alias for ko_KR.KSC5601 if I understand correctly.  (Would ko_KR.EUC-KR@SAP also be acceptable btw? I am not very sure about the normal form)

 * lt_LT.ISO-8859-4@SAP
 * lv_LV.ISO-8859-4@SAP
 * et_EE.ISO-8859-4@SAP

Baltic locales using ISO-8859-4 rather than modern ISO-8859-7.

 * de_DE.ISO-8859-1@SAP

Hannes said this would be because of many German customers running SuSE: we might want en_US.ISO-8859-1@SAP or en_GB.ISO-8859-1@SAP, say instead?
(it relates to collation of control-character iiuc)

 * cs_CZ.ISO-8859-2@SAP

This is a special Czech standard collation with numbers after letters.

 * ja_JP.SJIS@SAP (w/o shift state)

Ideally SAP would like us to merge the shiftless SJIS with the latest SJIS in glibc for sap-locale, or backport SJIS charset changes to SAP's Shift_JIS in the old saplocales packages.  A worst case would be to ship the old saplocales locale but this would be unsatisfactory since it is missing quite a lot of characters, eg some used for names, that were since added and included in current glibc.

I will probably need some help from the glibc guys with some of these.

Hannes, please check and correct any of my mistakes.  Thank you.
Comment 80 Hannes Kuehnemund 2009-03-18 05:30:34 EDT
(In reply to comment #79)
> The following locales are needed in the new sap-locale package:
>  * tr_TR.ISO-8859-9@SAP
> This is basically just the old Turkish locale in the old saplocales package.

correct
 
>  * ko_KR.euckr@SAP
> This is an alias for ko_KR.KSC5601 if I understand correctly.  (Would
> ko_KR.EUC-KR@SAP also be acceptable btw? I am not very sure about the normal
> form)

ko_KR.euckr@SAP is also fine. This indication is good, as Korean SAP customers tend to look for ko_KR.KSC5601. With ko_KR.euckr@SAP we have a good compromise
 
>  * lt_LT.ISO-8859-4@SAP
>  * lv_LV.ISO-8859-4@SAP
>  * et_EE.ISO-8859-4@SAP
> Baltic locales using ISO-8859-4 rather than modern ISO-8859-7.

correct
 
>  * de_DE.ISO-8859-1@SAP
> Hannes said this would be because of many German customers running SuSE: we
> might want en_US.ISO-8859-1@SAP or en_GB.ISO-8859-1@SAP, say instead?
> (it relates to collation of control-character iiuc)

Right, depending on your SAP on RHEL customer base, you should decide which locale to provide with a adapted LC_COLLATE, that has a UNIX like sorting.
 
>  * cs_CZ.ISO-8859-2@SAP
> This is a special Czech standard collation with numbers after letters.

cs_CZ.ISO-8859-2 and sk_SK.ISO-8859-2 sort numbers after letters according to standard ČSN 97 6030. We'd need a locale which does the sorting like all other locale, numbers before letters. The names of these locales would be

cs_CZ.ISO-8859-2@SAP
sk_SK.ISO-8859-2@SAP
 
>  * ja_JP.SJIS@SAP (w/o shift state)
> Ideally SAP would like us to merge the shiftless SJIS with the latest SJIS in
> glibc for sap-locale, or backport SJIS charset changes to SAP's Shift_JIS in
> the old saplocales packages.  A worst case would be to ship the old saplocales
> locale but this would be unsatisfactory since it is missing quite a lot of
> characters, eg some used for names, that were since added and included in
> current glibc.

As ja_JP.SHIFTJIS_X0213 has a shiftstate but the correct character map, a mix of both lcoales would be ideal. Japanese locales on UNIX platforms do not have a shiftstate. This shiftstate could lead to database inconstencies :(
Comment 82 Nils Philippsen 2009-03-19 04:56:51 EDT
Just an idea, maybe the package we ship should get a name that's easier to distinguish from the one SAP ship: "saplocales" vs. "sap-locale" is easily confused, especially when spoken. Perhaps something like "custom-locales-sap"?
Comment 84 Jens Petersen 2009-03-26 08:58:59 EDT
(In reply to comment #82)
> Just an idea, maybe the package we ship should get a name that's easier to
> distinguish from the one SAP ship: "saplocales" vs. "sap-locale" is easily
> confused, especially when spoken. Perhaps something like "custom-locales-sap"?  

That's a fair comment, I tend to agree - I think Hannes suggested sap-locale since that is the name of the package that Novell ships.
Comment 85 Hannes Kuehnemund 2009-03-30 07:49:26 EDT
The naming convention is up to you. My suggestion was sap-locale as this would make life easier for SAP as we can reference to this general name. If you feel unconfortable with sap-locale, you can use another name. But this will show our customers that Linux != Linux and it gets more complicated ...
Comment 105 Jens Petersen 2009-05-08 07:02:56 EDT
Ok here is an early preliminary test package

http://people.redhat.com/petersen/.sap/sap-locale.spec
http://people.redhat.com/petersen/.sap/sap-locale-2.2.5-3.fc10.src.rpm

* Fri May  8 2009 Jens Petersen <petersen@redhat.com> - 2.2.5-3
- reworked package to provide the correct locale requested by SAP (#467488)
- FIXME: missing still cs_CZ@SAP, sk_SK@SAP, and updated SAPSJIS
- FIXME: is %%pre install script still needed?

After installing the packages, I have:

$ locale -a | grep @SAP
et_EE.iso88594@SAP
ja_JP.sjis@SAP
ko_KR.euckr@SAP
lt_LT.iso88594@SAP
lv_LV.iso88594@SAP
tr_TR.iso88599@SAP


(In reply to comment #80)
> (In reply to comment #79)
> > The following locales are needed in the new sap-locale package:
> >  * tr_TR.ISO-8859-9@SAP
> > This is basically just the old Turkish locale in the old saplocales package.

Should be there

> >  * ko_KR.euckr@SAP
> > This is an alias for ko_KR.KSC5601 if I understand correctly.  (Would
> > ko_KR.EUC-KR@SAP also be acceptable btw? I am not very sure about the normal
> > form)
> 
> ko_KR.euckr@SAP is also fine. This indication is good, as Korean SAP customers
> tend to look for ko_KR.KSC5601. With ko_KR.euckr@SAP we have a good compromise

Done too.

> >  * lt_LT.ISO-8859-4@SAP
> >  * lv_LV.ISO-8859-4@SAP
> >  * et_EE.ISO-8859-4@SAP
> > Baltic locales using ISO-8859-4 rather than modern ISO-8859-7.

Should be defined.

> >  * de_DE.ISO-8859-1@SAP
> > Hannes said this would be because of many German customers running SuSE: we
> > might want en_US.ISO-8859-1@SAP or en_GB.ISO-8859-1@SAP, say instead?
> > (it relates to collation of control-character iiuc)
> 
> Right, depending on your SAP on RHEL customer base, you should decide which
> locale to provide with a adapted LC_COLLATE, that has a UNIX like sorting.

I leave this from now.

> >  * cs_CZ.ISO-8859-2@SAP
> > This is a special Czech standard collation with numbers after letters.
> 
> cs_CZ.ISO-8859-2 and sk_SK.ISO-8859-2 sort numbers after letters according to
> standard ČSN 97 6030. We'd need a locale which does the sorting like all other
> locale, numbers before letters. The names of these locales would be
> 
> cs_CZ.ISO-8859-2@SAP
> sk_SK.ISO-8859-2@SAP

I need some input from our glibc team about how to change the collation for these.

> >  * ja_JP.SJIS@SAP (w/o shift state)
> > Ideally SAP would like us to merge the shiftless SJIS with the latest SJIS in
> > glibc for sap-locale, or backport SJIS charset changes to SAP's Shift_JIS in
> > the old saplocales packages.  A worst case would be to ship the old saplocales
> > locale but this would be unsatisfactory since it is missing quite a lot of
> > characters, eg some used for names, that were since added and included in
> > current glibc.
> 
> As ja_JP.SHIFTJIS_X0213 has a shiftstate but the correct character map, a mix
> of both lcoales would be ideal. Japanese locales on UNIX platforms do not have
> a shiftstate. This shiftstate could lead to database inconstencies :(  

Right now it is using the old charmap from sap-locales, again need some help here
if we're going to sync with current glibc SJIS.

Hannes, how does this look so far?
Comment 106 Jens Petersen 2009-05-09 01:24:04 EDT
Meant to add to Nils and Hannes: I am flexible about the package naming and can see both perspectives.

Just bare in mind that even if our base package name is the same as Novell's, the actual packaging and manifest will most likely be different anyway.
Comment 107 Pravin Satpute 2009-05-14 00:31:49 EDT
Created attachment 343908 [details]
Czech Language Locale for Czech with SAP sorting order
Comment 108 Pravin Satpute 2009-05-14 00:35:26 EDT
Created attachment 343909 [details]
Slovak Language Locale for Slovak with SAP sorting order

It was using cs_CZ collation rules, 
so just included updated cs_CZ@SAP locale collation tables in LC_COLLATE Section of sk_SK
Comment 109 Hannes Kuehnemund 2009-05-14 03:05:01 EDT
Jens, thanks for providing the src package. I try to build it on RHEL5 and let you know about the testing results.

Praven, how can i use the attachments you created?

Additionally, can we please agree, that for cs_CZ and sk_SK we do not call it SAP sorting order (as it is not an SAP sorting order at all), but a Windows / Unix sorting order? It was not the idea of SAP but of the Czech institue of standards that both cs_CZ and sk_SK have a different sort oder then all other locales (characters before numbers). And it was not our idea that Windows and Unix ignore this sorting and adapt it back to the other standard locales ;-). SAP runs on all of these platforms and we have to ensure that we have a basic compatibility on locale level.
Comment 110 Pravin Satpute 2009-05-14 05:17:50 EDT
(In reply to comment #109)
> Jens, thanks for providing the src package. I try to build it on RHEL5 and let
> you know about the testing results.
> 
> Praven, how can i use the attachments you created?

for testing sorting using these locale,

1) generate locale data using localedef, use any test locale name

 localedef -i ./cs_CZ@SAP -f UTF-8 ./cs_TT

2) test sorting using sort function, ctest is test file with some random input,
be in same folder

LOCPATH=$PWD LC_ALL=cs_TT sort ctest

hoping this will help, else see

http://pravin-s.blogspot.com/2008/08/shortcut-method-for-testing-new-locale.html

http://pravin-s.blogspot.com/2008_03_01_archive.html


> SAP runs on all of these platforms and we have to ensure that we have a basic
> compatibility on locale level.

I have just changed collation part in locale.
Comment 111 Hannes Kuehnemund 2009-05-14 05:56:28 EDT
> localedef -i ./cs_CZ@SAP -f UTF-8 ./cs_TT

We have to use iso-8859-2 instead of utf-8. Will it work too?
Comment 112 Pravin Satpute 2009-05-14 06:02:53 EDT
Yeah, It will work, just give iso-8859-2 in CAP
Comment 113 Jens Petersen 2009-05-14 23:11:27 EDT
I will provide a new test package with Pravin's cs/sk locales.
Comment 114 Jens Petersen 2009-05-14 23:26:53 EDT
(In reply to comment #109)
> Additionally, can we please agree, that for cs_CZ and sk_SK we do not call it
> SAP sorting order (as it is not an SAP sorting order at all), but a Windows /
> Unix sorting order?

Yes, sorry: I think we just mean the locale that you (SAP) are requesting. :)

Let's just say the modified locale has "conventional alphanumeric collation"
(or "normal collation" for short)?
Comment 115 Jens Petersen 2009-05-15 06:01:51 EDT
Thanks Pravin for helping out with the collations. :)


Hannes, please try this srpm:

http://people.redhat.com/petersen/.sap/sap-locale-2.2.5-4.el5.src.rpm

* Fri May 15 2009 Jens Petersen <petersen@redhat.com> - 2.2.5-4
- add cs_CZ.ISO-8859-2@SAP and sk_SK.ISO-8859-2@SAP (thanks Pravin Satpute)


Remaining questions:
- update SAPSJIS to SJISX0213?
- are %%pre install script, etc still necessary??
Comment 116 Nils Philippsen 2009-05-28 04:26:00 EDT
Hannes, have you already tested this?

Meanwhile I'd like to raise the naming issue again as we haven't come to a conclusion yet: As SAP will continue to ship the "saplocales" package which contains locales with special non-Unicode encodings, I think we should give this package a suitably different name as "sap-locale" and "saplocales" are too easily confused. I don't think that the benefits of having the same package name as SLES outweigh this, as I'll end up documenting the package in my SAP notes on RHEL anyway.
Comment 120 Hannes Kuehnemund 2009-06-02 08:50:11 EDT
Hi Jens,

finally, I was able to test the package. I built it on RHEL5.2. I've seen that the version is 2.2.5, but shouldn't it be 2.5 (because glibc on RHEL5 is version 2.5 and any locale package is tied to the glibc, isn't it). Our locale package (saplocales) always has the same version as the glibc package.

Back to the testing. The sorting of sk_SK and cs_CZ works as expected:

[root]# LANG=cs_CZ.iso88592; echo -e "1\na\nb\n2" | sort
a
b
1
2
[root]# LANG=cs_CZ.iso88592@SAP; echo -e "1\na\nb\n2" | sort
1
2
a
b

The next test consits of checking the locale functions mblen, mbtowc, towupper, ctype and wctype on the provided locales.

cs_CZ.iso88592@SAP : no errors
et_EE.iso88594@SAP : no errors
ja_JP.sjis@SAP     : mblen + mbtowc errors
ko_KR.euckr@SAP    : no errors
lt_LT.iso88594@SAP : no errors
lv_LV.iso88594@SAP : no errors
sk_SK.iso88592@SAP : no errors
tr_TR.iso88599@SAP : towupper + wctype errors 

I'm currently checking with our internal i18n group what these errors mean and if they are critical. I get back to you as soon as possible.
Comment 122 Michael Waite 2009-06-03 10:36:46 EDT
I got an email from a Red Hat consultant that will be visiting a customer tomorrow:
<SNIP>
The customer has databases
and SAP running on HP_UX and is moving to RHEL5.2 x86_64 for the SAP
application part. He uses the de_DE.iso8859-1 locale on HP_UX. 

I would like to use and test the new package, but have no build
environment available for now. The bugzilla comments suggest that the
German SAP locale is not included anyhow for now...

Could you generate a test src rpm with the German SAP locale, so that i
can test this tomorrow at the customer site? I know it is very short
notice, and apologize for that. I'll be onsite in 20 hours :)
Comment 123 Hannes Kuehnemund 2009-06-03 10:46:34 EDT
In case you need a template for the HP-UX collation for en_US, please have a look at https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10650
Comment 126 Lutz Lange 2009-06-03 12:14:24 EDT
I really need the German SAP locale and want to install it in a way that is consistent with with possible future products.

I do have a German locale we used in another project. But am not 100% sure if this will fit the current project scenario, since back then the migration was done from Solaris to RHEL, not from HP_UX to RHEL as is my current case.

I'll send a mail with the internal link to the existing German SAP locale we used in the previous project.
Comment 127 Michael Waite 2009-06-03 12:35:46 EDT
Hi Lutz,
I spoke with Helge Deller about your needs an hour ago or so and he said he would see what we can collectively do to make sure have what you need for this customer.
Comment 128 Lutz Lange 2009-06-03 14:43:44 EDT
Nice thing. I'll check in the morning. 10h to go :-)
Comment 129 Helge Deller 2009-06-03 16:57:13 EDT
Hi Lutz,
I tried to reach Hannes (he is leaving for vacation today and will be off until June 12th), but I'm not sure if he will be able to help anyway.

From what I read above, my conclusion is, that Jens Petersen still needs to create a locale which fits with HP-UX's sort ordering (simulate it on Linux) and include it with your RH sap-locales (I didn't checked, but it seems to not be done yet).
Novell created such a locale (named de_DE.iso88591@SAP_HP on SLES), which has this behaviour. Maybe looking at their coding may help Jens to create the one for RH as well?
Citing now from Hannes' Blog at https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10650:
--------
: One operating system which ignores the special characters is Linux. 
: Novell does provide adapted locales starting with SLES10 SP2. 
: The sap-locale package contains a modified de_DE.iso88591
: (named de_DE.iso88591@SAP_HP) locale which sorts the special 
: characters based on the HP-UX sorting.
--------

So, I think we can't help in such a short timeframe right now...
Sorry.

Helge
Comment 130 Lutz Lange 2009-06-04 00:43:38 EDT
Ok, understood. Good hint with the Novell Package, i will investigate this further, if the locale i have ( something like de_DE.iso88591@SAP_Solaris ) does no get the desired results.

Tx for your efforts.
Lutz
Comment 132 Jens Petersen 2009-06-04 06:10:07 EDT
(In reply to comment #120)
> finally, I was able to test the package. I built it on RHEL5.2.

Thank you!

> I've seen that
> the version is 2.2.5, but shouldn't it be 2.5 (because glibc on RHEL5 is
> version 2.5 and any locale package is tied to the glibc, isn't it). Our locale
> package (saplocales) always has the same version as the glibc package.

Ok - I think the next version of the package will be
compat-locales-sap-2.5-1.el5.

> ja_JP.sjis@SAP     : mblen + mbtowc errors

Not sure what is happening there - there should not be any changes.

> tr_TR.iso88599@SAP : towupper + wctype errors 

I will try using the tr_TR@SAP from opensuse in the next package.
Comment 133 Jens Petersen 2009-06-04 06:26:00 EDT
Here is an updated package:

http://people.redhat.com/petersen/.sap/compat-locales-sap.spec
http://people.redhat.com/petersen/.sap/compat-locales-sap-2.5-1.el5.src.rpm


* Thu Jun  4 2009 Jens Petersen <petersen@redhat.com> - 2.5-1
- rename from sap-locale to distinguish package from SAP's saplocales package
- add posix locales for de_DE and en_US (Nils Philippsen)
- add iso14651_HP collation for de_DE from OpenSuSE's sap-locale package
- update tr_TR locale to OpenSuSE's sap-locale
- bump version to 2.5
Comment 134 Lutz Lange 2009-06-04 09:14:36 EDT
Ok, i tried you new package. I'm currently only interested in the sort order in the migration case from HP_UX to RHEL.

I can create a new locale after installing the new packages with :

# localedef -ci /usr/share/i18n/locale/de_DE@SAP_HP -f ISO-8859-1 de_DE.ISO-8859-1@HP

Using command line sort utilities on HP and RHEL and comparing the output ( using the new locale on RHEL ) i come close to matching.

on HP_UX :
$ sort test.txt
L
LEDER
leder
LEDER , FRANK
LEDER , MARCO
LEDERLE , ROMAN
LEDERP , Hans
M
Madeleine, Madame
M�del, Simo
Madel, Simone
Mbdeleine, Madame
mode
--now--
***test***
??one
!!two
##something

on RHEL5.2 x86_64:
LANG=de_DE.ISO-8859-1@HP
L
LEDER
LEDER , FRANK
LEDER , MARCO
LEDERLE , ROMAN
LEDERP , Hans
leder
M
Madeleine, Madame
Madel, Simone
M�del, Simo
Mbdeleine, Madame
mode
--now--
***test***
??one
!!two
##something

If you take a serious look at the output, you can see that it comes close. And if i change the sort command on RHEL to "sort -f" it matches up. Taking a closer look at the LC_COLLATE part of the locale definition, i doubt that i can modify the locale there the mimic the exact HP_UX sort behavior.

Any hints on how to do the "auto-fold" ? Or any other ideas that might help?
Comment 135 Jens Petersen 2009-06-04 21:00:15 EDT
Sorry yesterday's updated package was created on Fedora 11 (which uses
new sha256 hashes and so won't install on RHEL5).

Please try this new package instead:

http://people.redhat.com/petersen/.sap/compat-locales-sap.spec
http://people.redhat.com/petersen/.sap/compat-locales-sap-2.5-2.el5.src.rpm

* Fri Jun  5 2009 Jens Petersen <petersen@redhat.com> - 2.5-2
- drop the de_DE iso14651_HP collation for now
Comment 136 Hannes Kuehnemund 2009-06-15 14:41:24 EDT
Sorry for the delay, I've been in vacation. I was able to build the package on RHEL5.3 and found the following:

cs_CZ.iso88592@SAP : no errors
et_EE.iso88594@SAP : no errors
ja_JP.sjis@SAP     : mblen + mbtowc errors
ko_KR.euckr@SAP    : no errors
lt_LT.iso88594@SAP : no errors
lv_LV.iso88594@SAP : no errors
sk_SK.iso88592@SAP : no errors
tr_TR.iso88599@SAP : towupper + wctype errors 

Sorting for cs_CZ and sk_SK are okay.

Please find the error files and result files for ja_JP.sjis@SAP and tr_TR.iso88599@SAP. The errors should be self exlaining, some characters are handled in a wrong matter [e.g. tr_TR.iso88599@SAP -> Translation from upper case of 0xB5 to lower case failed.(Error flag = 8)].

Two additional comments from our side. We can also provide the command line tool, which is used for checking the compatibility of operating system locales as well as establish contact to out i18n group, responsible for all locale matters.
Comment 137 Hannes Kuehnemund 2009-06-15 14:44:18 EDT
Created attachment 347982 [details]
result files for problematic locales
Comment 139 Jens Petersen 2009-06-16 21:36:22 EDT
(In reply to comment #137)
> Created an attachment (id=347982) [details]
> result files for problematic locales  

Hannes, these results are for compat-locales-sap-2.5-2.el5.src.rpm?


(In reply to comment #136)
> Please find the error files and result files for ja_JP.sjis@SAP and
> tr_TR.iso88599@SAP. The errors should be self exlaining, some characters are
> handled in a wrong matter [e.g. tr_TR.iso88599@SAP -> Translation from upper
> case of 0xB5 to lower case failed.(Error flag = 8)].

The Turkish locale was the one from the old saplocales package and now substituted with the locale file from Novell's sap-locale package: so in both cases I wonder why that error is arising.  Will try to investigate.

For SJIS, we are using the locale from your saplocales-2.2.5.

Note the locales in our package are actually named:

 ja_JP.SJIS@SAP and tr_TR.ISO8859-9@SAP

following the default Red Hat naming of locales, if that matters.

> Two additional comments from our side. We can also provide the command line
> tool, which is used for checking the compatibility of operating system locales
> as well as establish contact to out i18n group, responsible for all locale
> matters.  

The checking tool would be helpful to save turn-around time, thank you.
Comment 140 Hannes Kuehnemund 2009-06-17 05:21:18 EDT
(In reply to comment #139)
> Hannes, these results are for compat-locales-sap-2.5-2.el5.src.rpm?

Yes, the results are from the rpm packages built from compat-locales-sap-2.5-2.el5.src.rpm.

> The Turkish locale was the one from the old saplocales package and now
> substituted with the locale file from Novell's sap-locale package: so in both
> cases I wonder why that error is arising.  Will try to investigate.

Novell ist creating the locales in their own responsibility with the help of our locale check tool. We assume that you found a bug in their implementation of the turkish locale. We will check on this, Thanks.

> For SJIS, we are using the locale from your saplocales-2.2.5.

Oh, I think this cannot work. In comment #79 you outlined what was our intension:

> Ideally SAP would like us to merge the shiftless SJIS with the 
> latest SJIS in glibc for sap-locale, or backport SJIS charset 
> changes to SAP's Shift_JIS in the old saplocales packages.

The ja_JP.SHIFTJISX0213 locale would be perfect, if it doesn't have the shift state. We learned from Novell that removing the shift state from that locale is so glibc intrusive that it can't be done. However, our ja_JP locale from the saplocales package contains own conversion routines (outside the glibc) which don't have a shift state. Our idea was, that both locales can be combined? I'm sorry if this doesn't work, I'm not a developer in that sense, therefore I have to rely on the arguments and comments from you.
 
> Note the locales in our package are actually named:
> ja_JP.SJIS@SAP and tr_TR.ISO8859-9@SAP
> following the default Red Hat naming of locales, if that matters.

Yes. The error files have a header with shows the name of the checked locales. The names there are: ja_JP.SJIS@SAP and tr_TR.ISO8859-9@SAP. Therefore I think I used the correct locales.

> The checking tool would be helpful to save turn-around time, thank you.  

I've attached the checking tool for x86_64. Place all three files into an empty temporary folder (empty, because the result files are written into it as well). To check for example the defective wctype function of tr_TR.ISO8859-9@SAP the script has to be called in the following way. Lines between the long arrows "------------------->" are input from your keyboard:

./nls_check -newloc -wctype
[...]
Continue this program ? [Y/N]
-- [Y] :
------------------->
----> Press Y
------------------->
Please input a locale name :
------------------->
----> Enter tr_TR.ISO8859-9@SAP
------------------->
Please enter a codepage name of tr_TR.ISO8859-9@SAP.
(Press 'h' for help) :
------------------->
----> Press 'h' shows:
------------------->
    1: ISO8859-1        (Western european, Latin-1)
    2: ISO8859-2        (Eastern european, Latin-2)
    3: ISO8859-4        (Lithuanian, Latin-4)
    4: ISO8859-5        (Cyrillic)
    5: ISO8859-6        (Arabic)
    6: ISO8859-7        (Greek)
    7: ISO8859-8        (Hebew)
    8: ISO8859-9        (Turkish)
    9: ISO8859-13       (Latin-7)
   10: ISO8859-15       (Latin-9)
   11: Shift JIS        (Japanese)
   12: KSC5601          (Korean)
   13: GB2312           (Chinese)
   14: BIG 5            (Taiwanese)
   15: TIS-620          (Thai)
   16: Asian Uni        (Japanese + Korean + Chinese + Taiwanese)
   17: Asian Uni-K      (Japanese + Korean)
   18: Asian Uni-C      (Japanese + Chinese)
   19: Asian Uni-T      (Japanese + Taiwanese)
   20: Diocletian       (Latin 1 + Greek)
   21: Eurojapan        (Latin 1 + Japanese)
   22: Nagamasa         (Japanese + Thai)
   23: SAP Uni          (Latin 1 + Latin 2 + Japanese)
   24: Silkroad         (Greek + Japanese)
   25: Transsiberian    (Russian + Japanese)
   99: Other CP         (Other codepage)
   :     ()
Please enter a codepage name of tr_TR.ISO8859-9@SAP.
(Press 'h' for help) :
------------------->
----> Enter '8' to compare your locale with the expected ISO8859-9 setting
------------------->
Please enter a direcotry for storing data.
-- Directory[Current directory]:
------------------->
----> Press Enter
------------------->
[...]
-- FILE NAME[result_wctype_tr_TR.ISO8859-9@SAP.txt]:
------------------->
----> Press Enter
------------------->
The result was written in the file 'result_wctype_tr_TR.ISO8859-9@SAP.txt'.
NLS_CHECK detected problematic characters.
Please look at the file 'err_wctype_tr_TR.ISO8859-9@SAP.log'.
[done]
Comment 141 Hannes Kuehnemund 2009-06-17 05:22:08 EDT
Created attachment 348236 [details]
nls_check for linuxx86_64
Comment 142 Jens Petersen 2009-06-18 21:46:55 EDT
*** Bug 249677 has been marked as a duplicate of this bug. ***
Comment 143 Jens Petersen 2009-06-18 21:55:58 EDT
*** Bug 249679 has been marked as a duplicate of this bug. ***
Comment 144 Jens Petersen 2009-06-18 22:53:32 EDT
*** Bug 249682 has been marked as a duplicate of this bug. ***
Comment 145 Jens Petersen 2009-06-19 00:46:22 EDT
(In reply to comment #140)
> Novell is creating the locales in their own responsibility with the help of
> our locale check tool. We assume that you found a bug in their implementation
> of the turkish locale. We will check on this, Thanks.

Ok I will also try to have a look - not sure what the cause is.

> The ja_JP.SHIFTJISX0213 locale would be perfect, if it doesn't have the shift
> state. We learned from Novell that removing the shift state from that locale is
> so glibc intrusive that it can't be done. However, our ja_JP locale from the
> saplocales package contains own conversion routines (outside the glibc) which
> don't have a shift state. Our idea was, that both locales can be combined? I'm
> sorry if this doesn't work, I'm not a developer in that sense, therefore I have
> to rely on the arguments and comments from you.

I haven't been able to do a detailed assessment but the 2.2.5 changes look
complicated and porting them to JISX0213 seems non-trival and a considerable
amount of work and since I don't even understand the details of the original changes I am not sure yet how and if they can be ported to JISX0213.
It might be more realistic to target that for a later version at this stage?

> I've attached the checking tool for x86_64.

Thank you, I will try it.
Comment 146 Jens Petersen 2009-06-19 03:51:57 EDT
(In reply to comment #145)
> > Novell is creating the locales in their own responsibility with the help of
> > our locale check tool. We assume that you found a bug in their implementation
> > of the turkish locale. We will check on this, Thanks.
> 
> Ok I will also try to have a look - not sure what the cause is.

I see the same errors with both the earlier tr_TR locale we used patched from saplocales and the one borrowed from Novell's package.
Comment 149 Hannes Kuehnemund 2009-06-29 10:01:18 EDT
Jens,

according to our offside happened email communication, your suggestion was to get back to this bugzilla. I think, if you could list the current open issues from your side I can comment them so that all on CC are aware of the current status.

Thanks
Comment 150 Jens Petersen 2009-06-29 23:20:15 EDT
I have tried various things but no progress I am afraid.

So still the same remaining test failures:

tr_TR.iso88599@SAP:
Error: Translation from upper case of 0xB5 to lower case failed.
Error: 0xFF should not be defined as a translatable character.
Error: 0xFF should not be defined as a case translatable character.

ja_JP.sjis@SAP: all the double errors

which I don't know how to fix yet or fully understand.

I will try to discuss them with Pravin today.
Comment 151 Jens Petersen 2009-06-30 04:28:30 EDT
Brief update: Pravin and I managed to create fixes for the tr_TR@SAP errors.

Tomorrow we will try to look more at the Japanese locale.
Comment 152 Hannes Kuehnemund 2009-06-30 04:43:26 EDT
Thanks Jens, there are really good news !!!!!
Comment 153 Jens Petersen 2009-07-03 04:45:05 EDT
Afraid no real news on ja_JP.SJIS@SAP.

err_mblen-ja_JP.SJIS@SAP.log:
Warning: 0xF040 is not defined as a double byte character,
         but the character is in the user definable area. (Error id = 3)
:
Warning: 0xF9FC is not defined as a double byte character,
         but the character is in the user definable area. (Error id = 3)

(Is there some explanation about this error id 3?)

err_mbtowc-ja_JP.SJIS@SAP.log:
Warning: 0xF040 is not defined as a proper double byte character,
         but the character is in the user definable area.(Error flag = 3)
:
Warning: 0xF9FC is not defined as a proper double byte character,
         but the character is in the user definable area.(Error flag = 3)

We are wondering, since they are all only warnings can they not be waived?

Otherwise can you provide more info on how these PUA unicode points are used?

Since it seems to be a major modification to the glibc locale
I think it is non-trivial for us to work on it.
Comment 154 Hannes Kuehnemund 2009-07-03 11:36:56 EDT
The explanation of "Error flag = 3" is given at the end of the err_mbtowc-ja_JP.SJUS@SAP.log. At the top it says

--------------------------------------------------------
Warning: 0xF040 is not defined as a proper double byte character,
         but the character is in the user definable area.(Error flag = 3)
--------------------------------------------------------

and at the bottom outlines:

--------------------------------------------------------
Error flag 3:
The problem is the character is not defined as a proper single byte character. Therefore, mbtowc does not work with the character.
--------------------------------------------------------

However, this doesn't make sense for me either :). Therefore I've asked my colleagues from i18n and update this BZ as soon as possible.

Regarding the major modification, the SAP SJIS part from saplocales comes in. We have coding which works outside the glibc. The Japanese locale from the original saplocales package works with nls_check, but does not provide all japanese characters. Our idea was, that you might hook on our implementation?
Comment 155 Jens Petersen 2009-07-06 03:29:03 EDT
This package update should fix the tr_TR towupper and wctype errors:

http://people.redhat.com/petersen/.sap/compat-locales-sap-1.0.1-1.el5_3.src.rpm
Comment 156 Russell Doty 2009-07-07 10:07:13 EDT
SAP, please test the package in comment 155 and report results here.
Comment 159 Hannes Kuehnemund 2009-07-08 03:30:58 EDT
Done. We've checked the outstanding errors (tr_TR and ja_JP) and the ones form the Turkish locale are fixed. The issues on the Japanese locale are still outstanding. In our last status call we agreed on releasing the package to the update channel w/o the Japanese locale as this topic seems to be more complicated. Okay?
Comment 160 Jens Petersen 2009-07-10 03:17:24 EDT
Thanks Hannes.  That is fine.
Comment 161 Jens Petersen 2009-07-10 03:21:59 EDT
But just to clarify:

Shall we leave the package as is or actually remove
the SAPSJIS locale be from the initial release?
Comment 162 Hannes Kuehnemund 2009-07-10 03:26:18 EDT
The best option is to remove the Japanese locale from the package as delivering a broken locale is not convenient. Japanese customers using SAP on Red Hat have to compile the SHIFTJIS_X0213 locale themselves to get at least a locale which is not as broken as the other one.
Comment 163 Chris Ward 2009-07-10 15:05:50 EDT
~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~

RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching.

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.
Comment 164 Russell Doty 2009-07-16 14:19:03 EDT
SAP, please confirm that this locales package has been verified and that there are no issues.
Comment 165 Hannes Kuehnemund 2009-07-16 16:32:15 EDT
I'm sorry, if my comment #159 was not clear enough. Using "Done" was meant as "Done, we tested the package on RHEL5 and it is okay". HTH
Comment 166 Jens Petersen 2009-07-17 00:31:12 EDT
(In reply to comment #165)
> I'm sorry, if my comment #159 was not clear enough. Using "Done" was meant as
> "Done, we tested the package on RHEL5 and it is okay". HTH  

No, it was clear enough - thanks! :)

Here is the (hopefully) final package which is now noarch:

http://people.redhat.com/petersen/.sap/compat-locales-sap-1.0.2-1.el5_3.src.rpm
http://people.redhat.com/petersen/.sap/compat-locales-sap-common-1.0.2-1.el5_3.noarch.rpm
Comment 171 errata-xmlrpc 2009-08-04 12:36:19 EDT
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 therefore 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/RHEA-2009-1194.html

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