Bug#952516: please support LC_CTYPE=UTF-8

2020-07-23 Thread Aurelien Jarno
On 2020-07-23 08:02, Harald Dunkel wrote:
> Not yet. Do you have some Posix document, RFC, best practice guideline, etc
> showing that it should be "C.UTF-8" instead of "UTF-8"? Something to present
> to Apple proving  that they are not Posix compliant?
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
> says
> 
>   "The contents of this string are implementation-defined."

Please have a look at:

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html

It says most notably:

| If the locale value has the form:
| 
| language[_territory][.codeset]
| 
| it refers to an implementation-provided locale, where settings of
| language, territory, and codeset are implementation-defined.

This format is used in many UNIXes, for instance AIX, Solaris, SCO
UnixWare, HP UX. That said, MacOS has the possibility to use other
format as said below:

| "An implementation may support other formats."

However it should not assume that other systems also support that
implementation specific format.

> I could live with having to run localedef once to define a locale UTF-8
> at installation time, but that is wiped out again and again, see #965323.

Each time the locales package is update, the format might have changed,
or at minimum the locales need to be regenerated to take into in account
possible changes in the locale sources.

> What would you suggest?

You can use the /etc/locale.alias mechanism, it's deprecated, but that
works for now. Just add the following line to that file:

UTF-8   C.UTF-8

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#952516: please support LC_CTYPE=UTF-8

2020-07-23 Thread Harald Dunkel

Not yet. Do you have some Posix document, RFC, best practice guideline, etc
showing that it should be "C.UTF-8" instead of "UTF-8"? Something to present
to Apple proving  that they are not Posix compliant?

https://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
says

"The contents of this string are implementation-defined."

I could live with having to run localedef once to define a locale UTF-8
at installation time, but that is wiped out again and again, see #965323.

What would you suggest?


Regards
Harri



Bug#952516: please support LC_CTYPE=UTF-8

2020-07-19 Thread Aurelien Jarno
On 2020-02-25 10:04, Harald Dunkel wrote:
> Package: locales
> Version: 2.29-10
> Severity: wishlist
> 
> Apparently MacOS 10.15 uses "UTF-8" instead of "C.UTF-8". This
> affects ssh terminal sessions from MacOS to Debian, e.g.
> 
>   # apt upgrade
>   :
>   :
>   Processing triggers for mime-support (3.64) ...
>   Processing triggers for libc-bin (2.29-10) ...
>   perl: warning: Setting locale failed.
>   perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_CTYPE = "UTF-8",
>   LC_COLLATE = "C",
>   LANG = "C"
>   are supported and installed on your system.
>   perl: warning: Falling back to the standard locale ("C").
>   perl: warning: Setting locale failed.
>   perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_CTYPE = "UTF-8",
>   LC_COLLATE = "C",
>   LANG = "C"
>   are supported and installed on your system.
>   perl: warning: Falling back to the standard locale ("C").
> 
> The workaround is to run
> 
>   localedef -i C -f UTF-8 UTF-8
> 
> on Debian, but probably others are affected by this problem
> as well. A central solution would be reasonable.
> 
> Do you think it would be possible to introduce "UTF-8" as an
> alias for "C.UTF-8"?

MacOS is wrong there. We definitely do no want to introduce such a local
in an uncoordinated way, as it will make things way more difficult to
rollback instead. Have you reported the issue to Apple?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#952516: please support LC_CTYPE=UTF-8

2020-02-25 Thread Harald Dunkel

Package: locales
Version: 2.29-10
Severity: wishlist

Apparently MacOS 10.15 uses "UTF-8" instead of "C.UTF-8". This
affects ssh terminal sessions from MacOS to Debian, e.g.

# apt upgrade
:
:
Processing triggers for mime-support (3.64) ...
Processing triggers for libc-bin (2.29-10) ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LC_COLLATE = "C",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LC_COLLATE = "C",
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

The workaround is to run

localedef -i C -f UTF-8 UTF-8

on Debian, but probably others are affected by this problem
as well. A central solution would be reasonable.

Do you think it would be possible to introduce "UTF-8" as an
alias for "C.UTF-8"?


Regards
Harri