After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698952 - GnomeWallClock "clock" property is NULL if the locale is not UTF-8
GnomeWallClock "clock" property is NULL if the locale is not UTF-8
Status: RESOLVED DUPLICATE of bug 707599
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
3.8.2
: 699353 (view as bug list)
Depends on:
Blocks: 699325
 
 
Reported: 2013-04-26 13:56 UTC by Thomas Wood
Modified: 2013-09-06 18:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas Wood 2013-04-26 13:56:27 UTC
The GnomeWallClock "clock" property is always NULL if the current locale doesn't specify UTF-8 encoding.
Comment 1 Bastien Nocera 2013-04-26 14:06:37 UTC
I'm betting on broken i18n given the lack of calls to bind_textdomain_codeset(). If that code worked before, it was purely accidental.
Comment 2 Matthias Clasen 2013-05-01 00:46:19 UTC
*** Bug 699353 has been marked as a duplicate of this bug. ***
Comment 3 Evgeny Bobkin 2013-07-25 07:02:33 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

the relevant commit is https://git.gnome.org/browse/gnome-desktop/commit/?id=a4dd7815aba059c8798094a277acccfdbc2f7179

https://bugzilla.gnome.org/show_bug.cgi?id=699325#c7

Correct me if I am wrong
Comment 4 Bastien Nocera 2013-07-25 07:24:24 UTC
(In reply to comment #3)
> This problem has been fixed in the development version. The fix will be
> available in the next major software release. Thank you for your bug report.
> 
> the relevant commit is
> https://git.gnome.org/browse/gnome-desktop/commit/?id=a4dd7815aba059c8798094a277acccfdbc2f7179
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=699325#c7

Then it's a dupe and needs to be marked as such.

> Correct me if I am wrong

Did you not test this?

*** This bug has been marked as a duplicate of bug 699325 ***
Comment 5 Evgeny Bobkin 2013-07-25 07:31:16 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > This problem has been fixed in the development version. The fix will be
> > available in the next major software release. Thank you for your bug report.
> > 
> > the relevant commit is
> > https://git.gnome.org/browse/gnome-desktop/commit/?id=a4dd7815aba059c8798094a277acccfdbc2f7179
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=699325#c7
> 
> Then it's a dupe and needs to be marked as such.
> 
> > Correct me if I am wrong
> 
> Did you not test this?
> 
I have tested it
https://bugzilla.gnome.org/show_bug.cgi?id=698942#c4

However it does not fixes the gnome-clocks issue, as was initially assumes it should.
That is why I would like to double check it by someone else.

Can you confirm this as well?
> *** This bug has been marked as a duplicate of bug 699325 ***
Comment 6 Evgeny Bobkin 2013-07-25 07:37:36 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > This problem has been fixed in the development version. The fix will be
> > available in the next major software release. Thank you for your bug report.
> > 
> > the relevant commit is
> > https://git.gnome.org/browse/gnome-desktop/commit/?id=a4dd7815aba059c8798094a277acccfdbc2f7179
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=699325#c7
> 
> Then it's a dupe and needs to be marked as such.
Thank you. You are right.
> 
> > Correct me if I am wrong
> 
> Did you not test this?
> 
> *** This bug has been marked as a duplicate of bug 699325 ***
Comment 7 Evgeny Bobkin 2013-07-25 09:58:21 UTC
This was fixed for me only because I have a patch applied locally:
https://bugzilla.gnome.org/show_bug.cgi?id=696497#c18

the issue is caused by the g_date_time_format (now, format_string) function

which returns NULL, if format_string contains an utf-8 character!!!
Comment 8 Bastien Nocera 2013-09-05 22:38:00 UTC
Master seems to work fine:

$ LC_ALL=en_GB.ISO8859-1 ./test-wall-clock
Thu 19:29
^C
$ LC_ALL=C ./test-wall-clock
Thu 19:30

How exactly do I reproduce the problem?
Comment 9 Evgeny Bobkin 2013-09-06 08:37:35 UTC
(In reply to comment #8)
> Master seems to work fine:
> 
> $ LC_ALL=en_GB.ISO8859-1 ./test-wall-clock
> Thu 19:29
> ^C
> $ LC_ALL=C ./test-wall-clock
> Thu 19:30
> 
> How exactly do I reproduce the problem?

As I have mentioned in my previous comment, the format string should contain at least one unicode character, like COLON, in all your tested cases only plain colon ":" were shown. So a locale in which COLON is used will fail.
Comment 10 Bastien Nocera 2013-09-06 18:37:30 UTC
Which is a known bug in glib, see bug 707599. So I'll close this.

*** This bug has been marked as a duplicate of bug 707599 ***