Description of problem:
We've opened this ticket for a new glibc package since the Japanese era name will be changed on May 1, 2019. According to the Japanese government, they are considering preliminary announcement around the spring/summer of 2018.
Checked the following thing:
@yoguma src]$ ldd `which date`
linux-vdso.so.1 => (0x00007ffedfffb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f11d5915000)
@yoguma src]$ LC_TIME=ja_JP.utf8 ltrace date +'%EY'
__libc_start_main(0x401ac0, 2, 0x7fffdea3ea58, 0x4096f0 <unfinished ...>
strrchr("date", '/') = nil
setlocale(LC_ALL, "") = "LC_CTYPE=en_US.utf8;LC_NUMERIC=e"...
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x402c50, 0, 0, 0x736c6974756572) = 0
getopt_long(2, 0x7fffdea3ea58, "d:f:I::r:Rs:u", 0x60d2a0, nil) = -1
clock_gettime(0, 0x7fffdea3e890, 2, 0) = 0
localtime(0x7fffdea3e810) = 0x7f93fc125d40
strftime(" \345\271\263\346\210\22030\345\271\264", 1024, " %EY", 0x7f93fc125d40) = 12
fwrite("\345\271\263\346\210\22030\345\271\264", 11, 1, 0x7f93fc121400) = 1
__overflow(0x7f93fc121400, 10, 11, 1024平成30年
) = 10
exit(0 <unfinished ...>
__fpending(0x7f93fc121400, 0, 64, 0x7f93fc121eb0) = 0
fileno(0x7f93fc121400) = 1
__freading(0x7f93fc121400, 0, 64, 0x7f93fc121eb0) = 0
__freading(0x7f93fc121400, 0, 2052, 0x7f93fc121eb0) = 0
fflush(0x7f93fc121400) = 0
fclose(0x7f93fc121400) = 0
__fpending(0x7f93fc1211c0, 0, 0x7f93fc122a00, 0xfbad000c) = 0
fileno(0x7f93fc1211c0) = 2
__freading(0x7f93fc1211c0, 0, 0x7f93fc122a00, 0xfbad000c) = 0
__freading(0x7f93fc1211c0, 0, 4, 0xfbad000c) = 0
fflush(0x7f93fc1211c0) = 0
fclose(0x7f93fc1211c0) = 0
+++ exited (status 0) +++
@yoguma src]$ find glibc-2.17-c758a686 | grep ja
Look at glibc-2.17-c758a686/localedata/locales/ja_JP:
Version-Release number of selected component (if applicable):
Fix for this has to come from upstream first so we have the correct and matching era name.
Once we have released an errata including the new errata data, will there be anything left for customers to do?
For example, could there any relinking be required, or any recompilation of code which they use?
(In reply to Christian Horn from comment #11)
> Once we have released an errata including the new errata data, will there be
> anything left for customers to do?
In fact we can write a kbentry *immediately* with steps to take to actually adjust the target system to handle the new era change.
The steps require compiling and installing a new locale.
> For example, could there any relinking be required, or any recompilation of
> code which they use?
>(In reply to Christian Horn from comment #11)
>> Once we have released an errata including the new errata data, will there be
>> anything left for customers to do?
Thanks Carlos, should now be covered by https://access.redhat.com/solutions/2749651 .
FWIW, openjdk seems to have implemented the new era now, with name NEWERA, which they
intend to replace then later. I guess they wanted to be sure to have time to debug
issues they might have with the change itself now that there is time, and later just
want to replace the era.
New Japanese era name was announced
more formal one : https://japantoday.com/category/national/japan-names-new-era-reiwa
glibc-2.17-289.el7 has new Japanese Era support
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.