(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.

Lets fix this in f19 first and backport.

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

(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.

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.

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.

(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?

Any news about this issue ?

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?

(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.

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