Bug 971416 - Locale alias no_NO.ISO-8859-1 not working.
Locale alias no_NO.ISO-8859-1 not working.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Florian Weimer
Arjun Shankar
: Patch
Depends On: 928729
Blocks: 1297579 1313485
  Show dependency treegraph
 
Reported: 2013-06-06 09:06 EDT by Remi Collet
Modified: 2016-11-03 04:20 EDT (History)
9 users (show)

See Also:
Fixed In Version: glibc-2.17-138.el7
Doc Type: Bug Fix
Doc Text:
Cause: The setlocale function in glibc did not re-check the locale archive after locale alias expansion. Consequence: Locale aliases such as “no_NO.ISO-8859-1” will not work in a default installation. Fix: glibc now checks the locale archive again after locale alias expansion. Result: Locale aliases work as expected.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 04:20:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch that fixes the problem (1.56 KB, patch)
2013-08-30 05:43 EDT, Alexandre Oliva
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 15969 None None None Never
Red Hat Product Errata RHSA-2016:2573 normal SHIPPED_LIVE Low: glibc security, bug fix, and enhancement update 2016-11-03 08:05:56 EDT

  None (edit)
Description Remi Collet 2013-06-06 09:06:06 EDT
Already reported as fedora bug #928729

From latest PHP build in RHEL-7
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Test setlocale() function : usage variations - Setting all available locales in the platform [ext/standard/tests/strings/setlocale_variation2.phpt]
=====================================================================

$ locale -a | grep no_NO
no_NO
no_NO.ISO-8859-1

Calling setlocale(LC_ALL, "no_NO.ISO-8859-1") fails.

I will just be happy to have a 0 failed tests in php ;)
Comment 2 Carlos O'Donell 2013-06-06 12:56:35 EDT
(In reply to Remi Collet from comment #0)
> Already reported as fedora bug #928729
> 
> From latest PHP build in RHEL-7
> =====================================================================
> FAILED TEST SUMMARY
> ---------------------------------------------------------------------
> Test setlocale() function : usage variations - Setting all available locales
> in the platform [ext/standard/tests/strings/setlocale_variation2.phpt]
> =====================================================================
> 
> $ locale -a | grep no_NO
> no_NO
> no_NO.ISO-8859-1
> 
> Calling setlocale(LC_ALL, "no_NO.ISO-8859-1") fails.
> 
> I will just be happy to have a 0 failed tests in php ;)

In RHEL7 we no longer have no_NO.

Instead we alias it to nb_NO via: /usr/share/locale/locale.alias 

In the locale.alias file we have:
...
no_NO		nb_NO.ISO-8859-1
no_NO.ISO-8859-1 nb_NO.ISO-8859-1
...
norwegian       nb_NO.ISO-8859-1
...

Which is why the locales appear in the list of `locale -a`.

However, a simple test program fails:
[carlos@dauntless ~]$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>

int
main (void)
{
  char *ret;
  ret = setlocale(LC_ALL, "no_NO.ISO-8859-1");
  if (ret == NULL)
    perror ("setlocale");
  else
    printf ("%s\n", ret);
  return 0;
}

[carlos@dauntless ~]$ gcc -Wall -pedantic -o test test.c
[carlos@dauntless ~]$ ./test
setlocale: No such file or directory
[carlos@dauntless ~]$ 

However, "no_NO" works, as does "norwegian" (another alias).

Using "nb_NO.ISO-8859-1" works as expected.

At a first glance I don't know what's going on.

In glibc locale/programs/locale.c looks like it correctly parses the locale.alias file which is why no_NO* is listed at all.

However it then seems like setlocale doesn't understand the alias.

The logic in intl/localealias.c (_nl_expand_alias) is different from that of locale.c, therefore there is room for error.

We will look into this issue.
Comment 3 Carlos O'Donell 2013-06-06 13:04:30 EDT
Lets fix this in f19 first and backport.
Comment 4 Remi Collet 2013-06-07 02:38:34 EDT
Proposal test case to detect regression in any locale

---
#include <locale.h>
#include <stdio.h>

int main (int argc, char *argv[]) {
	if (argc==1) printf("Missing arg\n");
	for (argc-- ; argc>0 ; argc--)
		if (!setlocale(LC_ALL, argv[argc]))
			printf("Broken: %s\n", argv[argc]);
	return 0;
}
---

so :

$ ./testcase  $(locale -a)
Broken no_NO.ISO-8859-1
Comment 5 Miroslav Franc 2013-06-07 04:04:37 EDT
(In reply to Remi Collet from comment #4)
> Proposal test case to detect regression in any locale

Thanks.  Looks very useful.  I'll add something like that into our test repository.
Comment 7 Carlos O'Donell 2013-08-07 18:51:15 EDT
We are delaying fixing this while we work on other higher priority issues. We will keep this issue updated as we get to fixing this, most likely in rhel-7.1, since adding localizations should be an acceptable thing to do in a y-stream update.
Comment 8 Alexandre Oliva 2013-08-30 05:43:15 EDT
Created attachment 792106 [details]
patch that fixes the problem

The problem seems to be that _nl_find_locale expects the archive to contain alias information for locale data present in the archive.  However, our build-time-created locale-alias.tmpl intentionally does not contain any aliases, and the install-time build-locale-archive doesn't add the desired aliases either.  As a result, in order for aliases present in /usr/share/locale/locale.alias to apply, locale information referenced by the aliases must be installed separately, rather than in the archive.

One way to address this problem is to modify the spec file so as to add such backward-compatibility aliases to the archive template.  Another is to install the attached patch, so that we search again in the archive after expanding an alias.
Comment 9 Carlos O'Donell 2013-09-03 10:42:19 EDT
(In reply to Alexandre Oliva from comment #8)
> Created attachment 792106 [details]
> patch that fixes the problem
> 
> The problem seems to be that _nl_find_locale expects the archive to contain
> alias information for locale data present in the archive.  However, our
> build-time-created locale-alias.tmpl intentionally does not contain any
> aliases, and the install-time build-locale-archive doesn't add the desired
> aliases either.  As a result, in order for aliases present in
> /usr/share/locale/locale.alias to apply, locale information referenced by
> the aliases must be installed separately, rather than in the archive.
> 
> One way to address this problem is to modify the spec file so as to add such
> backward-compatibility aliases to the archive template.  Another is to
> install the attached patch, so that we search again in the archive after
> expanding an alias.

This needs to go upstream first. Do you think we can convince upstream that one of these approaches is correct? I'd be happy for a more robust solution that expands the alias and retries the search.

Could you send your patch upstream and see what people say?
Comment 10 Remi Collet 2014-06-11 10:24:44 EDT
Any news about this issue ?
Comment 13 Alexandre Oliva 2014-10-31 04:28:37 EDT
Carlos, Remi, the patch was posted upstream, in response to Carlos' request, at https://sourceware.org/ml/libc-alpha/2013-09/msg00566.html

An upstream bug was opened, as indicated there.

However, the patch didn't get reviewed.  I expected Carlos to have seen it and reviewed it, since he asked for it to be posted there.

Carlos, any chance you could have a look?
Comment 15 Carlos O'Donell 2015-06-21 21:05:02 EDT
(In reply to Alexandre Oliva from comment #13)
> Carlos, Remi, the patch was posted upstream, in response to Carlos' request,
> at https://sourceware.org/ml/libc-alpha/2013-09/msg00566.html
> 
> An upstream bug was opened, as indicated there.
> 
> However, the patch didn't get reviewed.  I expected Carlos to have seen it
> and reviewed it, since he asked for it to be posted there.
> 
> Carlos, any chance you could have a look?

For the record this was reviewed upstream on 2015-01-20 and checked in, so the solution is upstream. However, we're not going to get to this work until the next release. Therefore it has been moved for review in rhel-7.3.0.
Comment 22 errata-xmlrpc 2016-11-03 04:20:41 EDT
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.

https://rhn.redhat.com/errata/RHSA-2016-2573.html

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