It's a more general issue: busybox is configured with CONFIG_LOCALE_SUPPORT
disabled, so setlocale(3) is never called for any applets.

The date binary simply calls strftime(3) to generate the output, which does
support locales if initialised properly.

Confirming as enhancement request.

Comment 2 Eero Tamminen 2010-05-04 17:34:17 UTC

Why busybox would need (to be bloated with) localization support?
Is there some use-case that is broken by it?

(say 3rd party application where this wouldn't be even easier to do in some
other way.)

(In reply to comment #2)
> Why busybox would need (to be bloated with) localization support?

Note that the impact of LOCALE_SUPPORT on busybox size is minimal (and only a
handful of applets do anything with it), the actual locale support code is
already in glibc.

Comment 4 Eero Tamminen 2010-05-04 19:43:49 UTC

(In reply to comment #3)
> Note that the impact of LOCALE_SUPPORT on busybox size is minimal (and only a
> handful of applets do anything with it), the actual locale support code is
> already in glibc.

Something being done by a library doesn't mean that it doesn't have an impact
on startup time, memory usage etc.  Certain locale initializations are
something that are clearly visible for both even for UI programs.

Right, I misunderstood "bloat" as binary size.  Testing on Diablo it doesn't
seem to have measurable impact on applet startup time.  It does slow sorting a
bit, but that's not unexpected (strcmp vs strcoll).

If "date" has to support only one locale, it should be a sensible one, not the
default broken one. mm/dd/yy makes no sense and is very misleading.

Comment 7 Eero Tamminen 2010-05-05 09:49:54 UTC

(In reply to comment #6)
> If "date" has to support only one locale, it should be a sensible one,
> not the default broken one.

I was going to reply that then you should be using -I (the sortable standard
ISO format), but noticed that our Buggybox segfaults with "date -I"
(NB#167068).


> mm/dd/yy makes no sense and is very misleading.

It's in the POSIX standard:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html

GNU date just shows the year with four digits.

(In reply to comment #7)
> I was going to reply that then you should be using -I (the sortable standard
> ISO format), but noticed that our Buggybox segfaults with "date -I"
> (NB#167068).

date +%x can be hardcoded in scripts that assume that the user has
correctly-configured locales (and a "date" that supports locales).

> > mm/dd/yy makes no sense and is very misleading.
> 
> It's in the POSIX standard:
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html

But this is an old and historical format, not good for the end user. Scripts
explicitly running under POSIX locales would probably not use %x. And if "date"
doesn't support locales, it is not POSIX compliant.

> GNU date just shows the year with four digits.

GNU date supports locales.

Comment 9 Eero Tamminen 2010-05-05 13:23:30 UTC

(In reply to comment #8)
> date +%x can be hardcoded in scripts that assume that the user has
> correctly-configured locales (and a "date" that supports locales).

If script expects specifically formatted output from something that is locale
specific, the script is broken.


> > It's in the POSIX standard:
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
> 
> But this is an old and historical format, not good for the end user.

Command line is not intended for normal end users. In general locale support
for command line stuff in Maemo is unsupported (some things may have locale
support, but you shouldn't count on it).

If you want to show something locale specific for an end user, you should
really use something that's appropriate for it (python, GUI widget for dates
etc).


So, as a summary, there's not even a proper use-case for locale support in
Busybox and this could be closed even as INVALID?

(Would anyway be WONTFIX for Fremantle.  If you want Busybox eventually
changed, you could start early and target MeeGo.  Early versions of it can also
run on N900. :-))

(In reply to comment #9)
> (In reply to comment #8)
> > date +%x can be hardcoded in scripts that assume that the user has
> > correctly-configured locales (and a "date" that supports locales).
> 
> If script expects specifically formatted output from something that is locale
> specific, the script is broken.

When output is locale-dependent, it is not meant to be reused as input by some
software. It is primarily for the end user.

> > But this is an old and historical format, not good for the end user.
> 
> Command line is not intended for normal end users.

Many end users use the command line and I don't think they should be regarded
as not normal. Anyway, scripts can also be run via graphical interfaces (more
than that, the end user doesn't necessarily knows that some script has been
run: the internal implementation doesn't matter to him). The output from such a
script can be sent back to the user under various forms. For instance, this can
be web page generation, or simply text files.

> If you want to show something locale specific for an end user, you should
> really use something that's appropriate for it (python, GUI widget for dates
> etc).

I don't see why python should be regarded as more appropriate than shell
scripts, in particular when considering performance and portability.

BTW, if you're just worried about startup time in scripts that don't need
locales, such scripts should start with LC_ALL=POSIX; export LC_ALL.

> So, as a summary, there's not even a proper use-case for locale support in
> Busybox and this could be closed even as INVALID?

Even though locale support could be limited, this is certainly not invalid.

> (Would anyway be WONTFIX for Fremantle.  If you want Busybox eventually
> changed, you could start early and target MeeGo.  Early versions of it can also
> run on N900. :-))

Locale support in MeeGo would be fine.

Comment 11 Eero Tamminen 2010-05-05 17:32:40 UTC

(In reply to comment #10)
>> So, as a summary, there's not even a proper use-case for locale support in
>> Busybox and this could be closed even as INVALID?
> 
> Even though locale support could be limited, this is certainly not invalid.

Please provide a list of SW relying on this / where this would be a problem.

(In reply to comment #11)
> Please provide a list of SW relying on this / where this would be a problem.

I don't know. This is the kind of problem one detects only when it occurs and
one looks at such output. And unfortunately, there would be no hope to get it
fixed quickly since system updates occur only every several months. So, to make
sure that the (known) bug won't be triggered in the future, it should be fixed
ASAP.

FYI, "date +%x" was working correctly on the N810 since I was using this method
to select the locale as described here: http://www.vinc17.net/maemo/#iso8601

Comment 13 Eero Tamminen 2010-05-06 10:39:14 UTC

(In reply to comment #12)
>> Please provide a list of SW relying on this / where this would be a problem.
> 
> I don't know. This is the kind of problem one detects only when it occurs and
> one looks at such output.

Well, do you know _any_  software that already uses it and which could be even
remotely useful & usable on a mobile device?


> FYI, "date +%x" was working correctly on the N810

With the pre-installed Busybox, not community one?  In Which Maemo SW version?

(In reply to comment #9)
> If you want Busybox eventually changed, you could start early and target
> MeeGo.

Pardon me for going slightly off-topic, but does that mean some MeeGo UX
variants will still ship busybox?   Previous discussion on this (thread
starting at
<http://lists.meego.com/pipermail/meego-dev/2010-February/000574.html>) seems
inconclusive.

I appreciate Harmattan is a different story, just wondering about the
longer-term view.

> Early versions of it can also run on N900.

FWIW the rootfs found in <http://repo.meego.com/MeeGo/devel/n900/images/>
doesn't contain busybox.

Comment 15 Eero Tamminen 2010-05-06 11:39:21 UTC

(In reply to comment #14)
> Pardon me for going slightly off-topic, but does that mean some MeeGo UX
> variants will still ship busybox?   Previous discussion on this (thread
> starting at:
 <http://lists.meego.com/pipermail/meego-dev/2010-February/000574.html>)
> seems inconclusive.

The issue is still open.  Let's see.

Personally I think there to be at least some chance that there will be some
version of MeeGo that is Busybox based.  Because this may mean that MeeGo won't
anymore be completely self hosting (able to build itself from scratch), at
least until all the issues are properly debugged & fixed, this issue may get as
hot debate as the deb vs. rpm one. :-)

Anyway, if Busybox will be used, I think it makes sense to make it correspond
as well to Desktop SW as possible (including localization support).  See e.g.
bug 4248 and bug 3032, especially the comment about upstream Busybox's
increasing compatibility.


> FWIW the rootfs found in <http://repo.meego.com/MeeGo/devel/n900/images/>
> doesn't contain busybox.

Moblin didn't have it and base of MeeGo is at least currently closer to Moblin
than Maemo.

(In reply to comment #12)
> FYI, "date +%x" was working correctly on the N810 since I was using this method
> to select the locale as described here: http://www.vinc17.net/maemo/#iso8601

On unmodified 5.2008.43-7 that loop outputs:

C     05/06/10
da_DK 05/06/10
de_DE 05/06/10
el_GR 05/06/10
en_GB 05/06/10
en_US 05/06/10
es_ES 05/06/10
es_MX 05/06/10
fi_FI 05/06/10
fr_CA 05/06/10
fr_FR 05/06/10
it_IT 05/06/10
nl_NL 05/06/10
no_NO 05/06/10
POSIX 05/06/10
pt_BR 05/06/10
pt_PT 05/06/10
ru_RU 05/06/10
sv_SE 05/06/10

while on the current community version (with locale-enabled busybox):
C     05/06/10
da_DK 06-05-2010
de_DE 06.05.2010
el_GR 06/05/2010
en_GB 06/05/10
en_US 05/06/2010
es_ES 06/05/10
es_MX 06/05/10
fi_FI 06.05.2010
fr_CA 2010-05-06
fr_FR 06.05.2010
it_IT 06/05/2010
nl_NL 06-05-2010
no_NO 06.05.2010
POSIX 05/06/10
pt_BR 06/05/2010
pt_PT 06-05-2010
ru_RU 06.05.2010
sv_SE 2010-05-06

(In reply to comment #13)
> > FYI, "date +%x" was working correctly on the N810
> 
> With the pre-installed Busybox, not community one?  In Which Maemo SW version?

I had the pre-installed Busybox, but that's a long time ago. I also had the
coreutils installed. So, perhaps when I wrote the code, the version from the
coreutils was taken (since this shouldn't have made any difference, I didn't
pay attention at that time). Now you have an example where different behaviors
on standard utilities add confusion...

*** Bug 10753 has been marked as a duplicate of this bug. ***

Comment 19 Andre Klapper 2010-11-22 17:16:05 UTC

WONTFIX for Fremantle (feature frozen), and as bug 11537 is fixed in Harmattan
this ticket is a WONTFIX for Harmattan too. Please feel free to file a bug in
bugs.meego.com if this still applies to MeeGo.

(In reply to comment #19)
> Please feel free to file a bug in bugs.meego.com if this still applies to MeeGo.

Well... the MeeGo compliance spec insists on GNU coreutils, bash etc in Core so
this would be irrelevant anyway.  FWIW busybox (1.16) packages are also present
in the 1.1 core repository in two flavours: "static", which is configured with
CONFIG_LOCALE_SUPPORT=y and "petitboot" (description: "a minimal configuration
intended for use with the Petitboot bootloader used on PlayStation 3", probably
copied straight over from the original Fedora SRPM to Moblin and now MeeGo)
which isn't.  Both of these look like they're made for specialised purposes
rather than general scripting or command line use.