[PATCH] [BZ 14094] Update locale data to Unicode 7.0.0

[Pravin Satpute]

Version2 of Patch.

>----- Original Message -----
>From: "Joseph S. Myers" <joseph@codesourcery.com>
>To: "Pravin Satpute" <psatpute@redhat.com>
>Cc: libc-alpha@sourceware.org, "Carlos O'Donell" <carlos@redhat.com>
>Sent: Sunday, June 22, 2014 2:34:30 AM
>Subject: Re: [PATCH] [BZ 14094] Update locale data to Unicode 7.0.0

>>On Sun, 22 Jun 2014, Pravin Satpute wrote:


>>  A.  Process for updating locales/i18n ctype with new Unicode release is
>> documented @ [1], I think it should get added either in WIKI, or docs
>> folder of glibc.

>The process should ideally be running a single command - no manual editing 
>at all.  (That command might be a script that wraps some other commands.)  
>If tempted to write instructions for running a sequence of commands and 
>editing the result, writing a script to automate that is better.

Now, we have single script. scripts/ctype-gen.sh, It generates unicode-ctype file.
Only for creating patch we need to copy content of unicode-ctype to i18n file. 

>>      Report/Analysis for backward compatibility is available AT
>> backward-compatibility5_1-to-7_0 [3]

>That report is a very useful starting point, but doesn't seem to explain 
>things at the human level.  What changes have there been to previously 
>supported characters, and why, in terms of Unicode character properties, 
>are those changes correct changes?  Maybe something more verbose that 
>names the characters individually and states what the old ctype 
>information was, and what the new information is, and what the relevant 
>Unicode proeprties are that explain the new information, would help.

Improved report available AT https://github.com/pravins/glibc-i18n/blob/master/unicode7-0/ctype-compatibility5_1-to-7_0

>You're changing how upper/lower/alpha properties are generated.  Does that 
>fix bug 14010?  If so, you can include [BZ #14010] in your ChangeLog 
>entry.  Does it obsolete the special cases in 
>gen-unicode-ctype.c:is_alpha?  If so, you should remove the parts of
>gen-unicode-ctype.c that are no longer used.  You should also confirm that 
>each of the special cases there is properly handled by the new logic - or 
>state explicitly that the handling of certain identified characters with 
>special cases is being deliberately changed, because the Unicode 
>properties for those characters are better than the special-case handling.

These classes now disable in gen-unicode-ctype.c and also moved this file to scripts/

>>  
>>  /* wchar_t uses ISO/IEC 10646 (2nd ed., published 2011-03-15) /
>> -   Unicode 6.0.  */
>> -#define __STDC_ISO_10646__		201103L
>> +   Unicode 6.0.
>> +   Unicode 7.0.0 Published on 2014 June 16   */
>> +#define __STDC_ISO_10646__		201406L

>maybe put 201304L there until such an amendment is published.

Done. Thanks for pointer.

>> diff --git a/scripts/check-backcompatibility.py b/scripts/check-backcompatibility.py
>> new file mode 100755
>> index 0000000..a56ac0a
>> --- /dev/null
>> +++ b/scripts/check-backcompatibility.py

>I think in scripts/ the name should be more specific about *what* is 
>having compatibility checked - scripts/ is for all of glibc, not just 
>locale data.

Now script name is check-compatibility.py I think starting name of scripts with ctype will 
help to identify them quickly.

>> +# Copyright (C) 2013-14, Pravin Satpute <psatpute@redhat.com>

>glibc contributions should be assigned to the FSF (and miscellaneous 
>programs would normally by GPLv2+ / LGPLv2.1+ unless there is some reason 
>to deviate from the norm for such programs in glibc).

Done.

Let me know if anything more missing.

Thanks,
Pravin Satpute
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-14094-14010.patch
Type: text/x-patch
Size: 254726 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20140625/ed08f03b/attachment.bin>