[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#522776: marked as done (debian-policy: mandate existence of a standardised UTF-8 locale)

Your message dated Fri, 16 Dec 2022 19:25:39 +0100
with message-id <Y5y4I5jzYJOBeqlp@angband.pl>
and subject line C.UTF-8 is built-in in glibc 2.35
has caused the Debian Bug report #522776,
regarding debian-policy: mandate existence of a standardised UTF-8 locale
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
522776: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy
Version: 3.8.1.0
Severity: wishlist

For the mksh regression tests, I need a UTF-8 locale working; most
systems either provide “en_US.UTF-8” or “en_US.utf8” with the former
being recommended.

Build-depending on locales-all has worked for me so far, except it
won’t do in Kubuntu where said package does not exist (workaround
is to run 「locale-gen en_US.UTF-8」 in a pbuilder hook, but that’s
almost certainly not allowed in debian/rules *and* requires root),
and fails on hurd-i386 recently (locales-all fails to install).

The promise of the etch release to bring UTF-8 support was not met
because a standard installation of etch does not supply any locale
which can be used for LC_CTYPE with UTF-8 support; only installing
locales-all, or installing locales and debconfing one will do so.
I do not know about lenny, though, I have to admit.

The most light-weight solution would be to
• introduce a “C.UTF-8” locale, as some other OSes did, which is
  equivalent to the “C” (POSIX) locale in all respects *except*
  for LC_CTYPE, where it uses UTF-8 instead of a 7/8-bit charac-
  ter set or encoding
• deliver the “C.UTF-8” locale with the base system
• allow Debian packages to depend on its existence, both at
  build and run time

A more controversial solution would be to do the second and third
point of the above with the “en_US.UTF-8” locale, but that would
be favouring US americanism. (On the other hand, it’s *the* one
most widely spread UTF-8 capable locale available, and as such,
the mksh regression tests use it upstream already.)

Thanks in advance.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base                      <none>     (no description available)

-- no debconf information

--- End Message ---
--- Begin Message --- 
The C.UTF-8 locale is always present as of glibc 2.35, and has existed in
Debian for a long long while.

Thus, this bug can be closed as implemented.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄⠀⠀⠀⠀

--- End Message ---
Reply to: