Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-07 Thread Ansgar
Michael Stone writes:
> On Thu, Feb 07, 2019 at 09:20:07PM +0100, Ondřej Surý wrote:
>>en_DK.UTF-8 is a good default locale?
>
> I think the suggestion of just "en" made the most sense--specify the
> language and an arbitrary set of rules that aren't tied to a specific
> country.

C.UTF-8 has the default of already existing and always being available.
Other locales are not guaranteed to be around (well, except "C").

FWIW systemd will set LANG=C.UTF-8 if no other locale is specified since
systemd 240:

 * When no /etc/locale.conf file exists (and hence no locale settings
   are in place), systemd will now use the "C.UTF-8" locale by default,
   and set LANG= to it. This locale is supported by various
   distributions including Fedora, with clear indications that upstream
   glibc is going to make it available too. This locale enables UTF-8
   mode by default, which appears appropriate for 2018.

That seems a reasonable choice and d-i could just use that by not
specifying any locale if the user wishes so.

(There is a small problem that getty@.service unsets LANG again.)

(And you get 24-hour time, but very strange Endian in C.UTF-8:
  WEEKDAY MMM DD HH:MM:SS TZ 
while en_US.UTF-8 has at least DD MMM ...  Having
  -MM-DD HH:MM:SS[+]
instead would be much nicer if we were to create an arbitrary set of new
rules for a new universal "en" locale ;-) )

Ansgar



Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

2019-02-07 Thread Ansgar
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
> On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> > How would this locale differ from C.UTF-8? Is the only difference
> > that C.UTF-8 has strict lexicographical sorting, whereas "en" would
> > have
> > case-insensitive sorting like en_GB.utf8 does? (If that's the only
> > difference, then perhaps something like "LANG=C.utf8
> > LC_COLLATE=en_US.utf8"
> > is enough.)
> 
> POSIX specifies the output format for various utilities in the C locale, 
> which defeats my understanding of the purpose of this proposal. So, for 
> example, in ls -l:

I don't think the "C.UTF-8" locale covered by any promises POSIX might
make for "C".  (Nor is what happens when no LC_*, LANG vairables are
set at all.)

Ansgar



Bug#909047: libc6.preinst: possible typo in 's/\bsamaba\b/smbd/g'

2018-09-17 Thread Ansgar Burchardt
Package: libc6
Version: 2.27-6
Severity: normal

libc6.preinst includes:

  -e's/\bsamaba\b/smbd/g'

This looks like a typo to me.  I assume it should be samba instead of
samaba?

Ansgar