Bug 473445 - en_GB locale DOW starts Tuesday and the 52nd week is listed as week ending 20th Dec
en_GB locale DOW starts Tuesday and the 52nd week is listed as week ending 20...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
10
All Linux
medium Severity low
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
: EasyFix, Patch, Triaged
: 474104 474566 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-28 10:33 EST by Lee Ball
Modified: 2009-12-18 02:00 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:00:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Screenshot of Calendar in action (37.60 KB, image/png)
2008-11-28 10:33 EST, Lee Ball
no flags Details
Date applet in action (67.98 KB, image/png)
2008-12-01 09:30 EST, markm
no flags Details
a patch for the change to the locale file (425 bytes, patch)
2009-02-25 14:51 EST, cje
no flags Details | Diff
a patch to update the spec file to include the previously attached new patch (1.24 KB, patch)
2009-02-25 14:57 EST, cje
no flags Details | Diff
fix LC_TIME in en_GB (1.61 KB, patch)
2009-03-16 09:15 EDT, cje
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 7068 None None None Never

  None (edit)
Description Lee Ball 2008-11-28 10:33:29 EST
Created attachment 325009 [details]
Screenshot of Calendar in action

Description of problem:
In the Calendar applet in Gnome, the first day of the week is listed as Tuesday when it should be Sunday, the first work day is Monday.

Also, the 1st week of 2009 is listed as week starting 23rd of December and the 52nd week of 2008 is listed as week ending 20th November.


Version-Release number of selected component (if applicable):
Gnome 2.24.1


How reproducible:
Everytime

Steps to Reproduce:
1. Set locale to en_GB
2. Open calendar by clicking on the clock in Gnome
  
Actual results:
Tuesday is listed as the start of the week
The first week of 2008 is listed as the second week.

Expected results:
The first day of the week should be Sunday and first working day Monday but Sunday should be first in the column after Week of the Year.

Additional info:
The issue appears to be with these sections in /usr/share/i18n/locales

week    7;19971201;4
first_weekday 2
first_workday 2
Comment 1 markm 2008-12-01 09:29:29 EST
The first day of the week in en_GB locale should be Monday, not Tuesday or Sunday.

Anyway, I am experiencing the same issue, see screenshot attached.
Comment 2 markm 2008-12-01 09:30:39 EST
Created attachment 325236 [details]
Date applet in action
Comment 3 markm 2008-12-01 09:51:04 EST
(In reply to comment #1)
> The first day of the week in en_GB locale should be Monday, not Tuesday or
> Sunday.

at least it used to be that way in Fedora 9 and earlier versions (I mean Monday as a first day of the week, not Sunday).
Comment 4 Ray Strode [halfline] 2008-12-02 13:43:42 EST
*** Bug 474104 has been marked as a duplicate of this bug. ***
Comment 5 Philip Frampton 2008-12-03 04:05:21 EST
I have the same issue with en_GB. I checked en_US and it appears to work (although 1st day is Sunday). I tried fr_FR and again it works, first day is Monday.

So I copied the:

week    7;19971201;4
first_weekday 1
first_workday 1

From fr_FR to en_GB and there is no change. Week still starts on Tuesday. The locale file for en)GB even listed MON as the first day. So it would appear that for some reason the date applet is not reading en_GB or is reading the wrong en_GB.
Comment 6 Ray Strode [halfline] 2008-12-04 09:59:11 EST
*** Bug 474566 has been marked as a duplicate of this bug. ***
Comment 7 Ray Strode [halfline] 2008-12-04 14:15:00 EST
seems to be a libc locale data issue.

nl_langinfo (_NL_TIME_FIRST_WEEKDAY) returns 2 instead of 1 for en_GB.utf8.

reassigning...
Comment 8 Mark Knoop 2008-12-15 05:30:39 EST
Disappointing that this was not fixed in the 2.9-3 update... I'm not sure why this is marked Severity: Low. This is a fairly obvious and embarrassing bug with an easy fix.

http://sourceware.org/bugzilla/show_bug.cgi?id=7068
Comment 9 Philip Frampton 2008-12-15 07:34:41 EST
The patch in that link doesn't work for me (or I've made a mistake).

I changed :

week    7;19971201;4

to

week    7;19971130;4

in /usr/share/i18n/locales/en_GB and restarted. No change. I even removed the clock applet and re-added it.

Also, I've read the ISO standard and 7;19971201;4 is correct for en_GB. SO I think the problem might be with the clock applet. Note evolution doesn't have this problem. Can someone confirm whether this bug appears in KDE or some other non-gnome environment.
Comment 10 Mark Knoop 2008-12-15 09:58:16 EST
> Also, I've read the ISO standard and 7;19971201;4 is correct for en_GB.

You are correct - GB week starts on Monday. The correct values are:

week    7;19971201;4
first_weekday 1
first_workday 1

But editing /usr/share/i18n/locales/en_GB won't help - I think you would need to recompile glibc-common. The reason the bug doesn't appear in evolution is because it has its own first-weekday preference. Likewise, cal ignores first-weekday from locale.

It is almost unbelievable that after years of the en_GB locale being broken by having the week starting on Sunday, it has now been "fixed" incorrectly!
Comment 11 Mark Knoop 2008-12-15 12:29:29 EST
I can confirm that rebuilding glibc-common works.

yumdownloader --source glibc
rpm -i glibc-2.9-3.src.rpm
tar xvfj rpmbuild/SOURCES/glibc-20081113T2206.tar.bz2 
vim glibc-20081113T2206/localedata/locales/en_GB (edit as above)
rm glibc-20081113T2206/localedata/locales/en_GB~
tar -cjf glibc-20081113T2206.tar.bz2 glibc-20081113T2206/
mv glibc-20081113T2206.tar.bz2 rpmbuild/SOURCES/
rpmbuild -bb rpmbuild/SPECS/glibc.spec 
su -c "rpm -ivh --replacepkgs --replacefiles rpmbuild/RPMS/x86_64/glibc-common-2.9-3.x86_64.rpm"

Logout.

There's already a fedora patch of en_GB in the glibc sources - *please* add this one also instead of just waiting for upstream to correct.
Comment 12 Chris Nolan 2009-01-31 11:04:08 EST
(In reply to comment #11)
> I can confirm that rebuilding glibc-common works.

Me too. The instructions above work just fine (F10 x86_64 here). Would be really good to see an official patch/fix for this as it is very annoying and very apparent.

Not convinced that GB/UK weeks start on a Monday anyway, I live here and to me it is always a Sunday for new week, but that's for another discussion.
Comment 13 James Gregory 2009-02-01 07:14:16 EST
I'm from the UK, and I've always considered the UK week to start on a Monday (as it has in previous versions of Fedora). Any idea when this is going to be fixed - while it isn't a problem, it is quite annoying...
Comment 14 Kevin R. Page 2009-02-01 08:02:28 EST
(In reply to comment #13)
> while it isn't a problem, it is quite annoying...

It *is* a problem.

Since this error was introduced I've made several (real-life) date based errors because I'm used to quickly glancing at the clock/date applet to work out dates <-> days of week.

Sure, I should probably have examined the column headings in more detail, but that's not human nature - in the time I've been using the applet I've trained myself to expect the left column to be Monday. That's the point of it - it's quick and easy to use - and it was great for this use case.

The fool-proof way of avoiding these mistakes has been to remove the applet.

Suggest reporter or owner add the EASYFIX keyword?
Comment 15 Philip Frampton 2009-02-01 09:35:26 EST
I'm glad someone else has voiced that opinion, because I too have found it incredibly annoying that I can't quickly and easily look across a week. I've followed the above advice and recompiled glibc, but if there is a critical flaw in glibc and a new version gets pushed I'm going to have to do it again until the patch is submitted.
Comment 16 James Gregory 2009-02-01 09:42:25 EST
I've made it known on the sourceware bug report that that patch is invalid, and can it be updated to the correct days.
Comment 17 Lee Ball 2009-02-02 07:16:00 EST
I appear to be getting an issue when creating the RPM, this is the last output I got from rpmbuild -bb rpmbuild/SPECS/glibc.spec

make[2]: Entering directory `/root/rpmbuild/BUILD/glibc-20081113T2206/timezone'
make[2]: *** [/root/rpmbuild/BUILDROOT/glibc-2.9-3.x86_64/usr/share/zoneinfo/right/Asia/Riyadh89] Segmentation fault
make[2]: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206/timezone'
make[1]: *** [timezone/subdir_install] Error 2
make[1]: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206'
make: *** [install] Error 2
make: Leaving directory `/root/rpmbuild/BUILD/glibc-20081113T2206/build-x86_64-linuxnptl'
error: Bad exit status from /var/tmp/rpm-tmp.srAOUT (%install)
Comment 18 Steve Milner 2009-02-09 05:00:21 EST
I am also suffering from an inability to create the new RPM with the same fault as noted in comment #17

Regards,

Steve Milner
Comment 19 cje 2009-02-25 14:51:35 EST
Created attachment 333211 [details]
a patch for the change to the locale file
Comment 20 cje 2009-02-25 14:57:10 EST
Created attachment 333212 [details]
a patch to update the spec file to include the previously attached new patch

now you can install the src rpm, add the new patch file to the SOURCES folder, apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4 version which can be applied with yum --nogpgcheck localinstall.

if you're on i386 with an i686 glibc you might need to rebuild twice - once including the --target i686 switch.

i've tried this on i386/i686 and it's working.  i'll try building it on x86_64 tomorrow and see if i get the problem that was reported in comment #17 and comment #18.
Comment 21 Steve Milner 2009-02-26 05:42:30 EST
I have tried the patches, and get this error while performing the rpmbuild

make[2]: *** [/home/steve/rpmbuild/BUILD/glibc-20081113T2206/build-x86_64-linuxnptl/sunrpc/rpcsvc/bootparam_prot.stmp] Segmentation fault
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/steve/rpmbuild/BUILD/glibc-20081113T2206/sunrpc'
make[1]: *** [sunrpc/others] Error 2
make[1]: Leaving directory `/home/steve/rpmbuild/BUILD/glibc-20081113T2206'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.OTqEnw (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.OTqEnw (%build)

Sorry.

Steve
Comment 22 cje 2009-02-26 08:07:47 EST
re comment #21: yup.  that appears to be x86_64 specific and also not related to the patch - the same thing happens if you try to rebuild glibc without the patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)

can someone confirm it works okay on i386?
Comment 23 markm 2009-02-26 08:34:29 EST
(In reply to comment #20)
> Created an attachment (id=333212) [details]
> a patch to update the spec file to include the previously attached new patch
> 
> now you can install the src rpm, add the new patch file to the SOURCES folder,
> apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4
> version which can be applied with yum --nogpgcheck localinstall.

a lame question - how to apply the patch?

patch my.patch

does nothing :(
Comment 24 markm 2009-02-26 08:35:44 EST
when I type:

patch -p1 <my.patch or patch <my.patch, I get this:

[root@m4300 SOURCES]# patch -p1 <my.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- glibc-20081113T2206/localedata/locales/en_GB-2.9-3	2009-02-24 17:26:43.000000000 +0000
|+++ glibc-20081113T2206/localedata/locales/en_GB	2009-02-24 17:28:13.000000000 +0000
--------------------------
File to patch:
Comment 25 cje 2009-02-26 08:46:18 EST
(In reply to comment #23)
> (In reply to comment #20)
> > Created an attachment (id=333212) [details] [details]
> > a patch to update the spec file to include the previously attached new patch
> > 
> > now you can install the src rpm, add the new patch file to the SOURCES folder,
> > apply /this/ patch to the spec file and then rebuild.  it will make a 2.9-4
> > version which can be applied with yum --nogpgcheck localinstall.
> 
> a lame question - how to apply the patch?
> 
> patch my.patch
> 
> does nothing :(

apologies.  to apply the patch to the spec file i do this:

cd to ~/rpmbuild
download the spec file patch as glibc.spec-2.9-3-2.9-4.diff
patch -p0 < glibc.spec-2.9-3-2.9-4.diff

that should work.  :-)
Comment 26 markm 2009-02-26 09:52:44 EST
Awesome!

that worked for me :) also, I've managed to rebuild glibc and installed it - after restart finally Monday is a first day of the week in date-applet :)

many thanks!
Comment 27 cje 2009-02-26 10:03:51 EST
wow, that was quick!  it took me a few hours to rebuild (i386 and i686).

thanks for checking and confirming.  hopefully someone fedora-ish will be able to check in this change soon.  :-)
Comment 28 Steve Milner 2009-02-26 11:29:11 EST
(In reply to comment #22)
> re comment #21: yup.  that appears to be x86_64 specific and also not related
> to the patch - the same thing happens if you try to rebuild glibc without the
> patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)
> 
> can someone confirm it works okay on i386?

Thank you for all your help regardless.

I'm afraid I haven't got the skills to even begin to fix that - sorry.

Regards,

Steve
Comment 29 markm 2009-02-26 11:39:02 EST
(In reply to comment #22)
> re comment #21: yup.  that appears to be x86_64 specific and also not related
> to the patch - the same thing happens if you try to rebuild glibc without the
> patch.  suggestions welcome :-)  (i've asked about it on fedora-devel-list.)
> 
> can someone confirm it works okay on i386?

it seems to work ok on i386, will test it on my home machine too (also i386).
not using x86_64 yet :)
Comment 30 cje 2009-03-16 09:15:22 EDT
Created attachment 335339 [details]
fix LC_TIME in en_GB

updated to include corresponding fix to the 'day' and 'abday' arrays of strings so that they both start with "Mon"/"Monday".  sorry i missed this before - hadn't bothered to wade through the unicode values .. or read the man pages!

see `man 5 locale`, ISO 14652 (apparently) and http://sourceware.org/ml/libc-alpha/2008-06/msg00015.html for further details.
Comment 31 cje 2009-03-16 09:21:17 EDT
i haven't actually tried the new patch yet.  it might well break any apps which (apparently incorrectly) rely on the 'day' and 'abday' arrays starting with "Sunday" ... which might well be all/most apps.

please try it out with any apps you can think of which display weekdays.  please check what they say both before and after this latest patch.  cheers.
Comment 32 markm 2009-03-16 09:27:42 EDT
(In reply to comment #31)
> i haven't actually tried the new patch yet.  it might well break any apps which
> (apparently incorrectly) rely on the 'day' and 'abday' arrays starting with
> "Sunday" ... which might well be all/most apps.
> 
> please try it out with any apps you can think of which display weekdays. 
> please check what they say both before and after this latest patch.  cheers.  

I have applied solution mentioned above and it works fine for me. Date / weather applet is showing dates correctly now. Evolution uses its own locale settings, so it does not apply there.

This used to show Tuesday as first day of the week so I assume, anything relaying on that should work incorrectly anyway.

The one thing which is not solved yet is time - I guess UK uses 24h time (see stations, airports etc) not 12h - apparently Evolution uses locale settings for emails list and despite calendar settings it shows there 12h time rather then 24h as set in Calendar's settings.
Comment 33 cje 2009-03-19 12:37:49 EDT
(In reply to comment #32)
> I have applied solution mentioned above and it works fine for me. Date /
> weather applet is showing dates correctly now. Evolution uses its own locale
> settings, so it does not apply there.
> 
> This used to show Tuesday as first day of the week so I assume, anything
> relaying on that should work incorrectly anyway.
> 
> The one thing which is not solved yet is time - I guess UK uses 24h time (see
> stations, airports etc) not 12h - apparently Evolution uses locale settings for
> emails list and despite calendar settings it shows there 12h time rather then
> 24h as set in Calendar's settings.  

are you sure you're using the new patch from comment #30, instead of the patch from comment #19?  i've just tried the new one (from comment #30) and now the weeks start on the correct _date_ (this week starts on the 16th) but the text names of the days are wrong - gnome's panel clock says that the 16th was a tuesday, as does evolution.

speaking of evolution, the same is true of the calendar views and email lists in my evolution - so it looks like it's using the system locale settings now, not its own.  can you check what version of evo you're using?

i _think_ the UK default would be 12h, not 24h but i don't know for sure.  i'm also not sure that's even specified in the locale settings.  and if it is then i'm not sure whether evo should prefer system settings or panel calendar settings.
Comment 34 cje 2009-03-19 12:41:47 EDT
Jakub, what do you think we should do with this next?  i suspect we should go ahead with my first patch (from comment #19) - ideally pretty soon as it'd be great to have the days and dates looking right for UK users of F11!

then we (or the glibc people) can have a separate exercise to sort out the arrays of textual day names.  might need a very coordinated approach changing glibc for many locales at the same time as applying fixes to the major users of those strings.
Comment 35 markm 2009-03-19 12:59:13 EDT
(In reply to comment #33)
> are you sure you're using the new patch from comment #30, instead of the patch
> from comment #19?  i've just tried the new one (from comment #30) and now the
> weeks start on the correct _date_ (this week starts on the 16th) but the text
> names of the days are wrong - gnome's panel clock says that the 16th was a
> tuesday, as does evolution.

I've applied patch from comment #19 and that one works, haven't tried patch from comment #30 yet.

Date/Time Applet shows dates correctly for me (this week started on Monday, 16th), Evolution shows first day of the week correctly on Monday, 16th.

> speaking of evolution, the same is true of the calendar views and email lists
> in my evolution - so it looks like it's using the system locale settings now,
> not its own.  can you check what version of evo you're using?

I am using Evolution 2.24.5, evolution-2.24.5-1.fc10.i386, calendar shows date correctly as set in Evolution's setting (if I change first day of the week to Sunday, it correctly changes date widget to Sunday, 15th for current week).

> i _think_ the UK default would be 12h, not 24h but i don't know for sure.  i'm
> also not sure that's even specified in the locale settings.  and if it is then
> i'm not sure whether evo should prefer system settings or panel calendar
> settings.  

I am working in English company, we use 24h clock in there in our communication, at stations / airports time is shown using 24h clock, so I assume, it's default for this country :) Regardless of the default setting, I think locale should be easily amendable by users. At the moment there is no easy way to change locale. I cannot set 24h clock for my system - so Evolution is showing time using 12h clock on mail list, I can change it in calendar, but calendar's settings don't apply on mail list. Also I like date in format YYYY-MM-DD, but UK's date format is set to DD/MM/YYYY...
Comment 36 cje 2009-04-16 12:12:20 EDT
looks like the x86_64 problem might have been sorted out - not sure how.  myself and a colleague have both been able to rebuild on x86_64 today.

Steve, can you give it another try (after a 'yum update' on fedora 10) ?

it's still the patch from comment #19 that's best for now.
Comment 37 Steve Milner 2009-04-20 11:08:12 EDT
Hi Need

I've got the x86_64 version to build now without any problems.

However, and I'm sure this is just stupidity on my part...

I gave glibc.i686 (required for whole heap of dependencies)

but when I:

rpmbuild -bb --target=i686 rpmbuild/SPECS/glibc.spec

I get:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for i686-redhat-linux-gcc... gcc
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
error: Bad exit status from /var/tmp/rpm-tmp.JbFooG (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.JbFooG (%build)

I will continue to research this myself and I will post again if I find the solution.

Regards,

Steve
Comment 38 Steve Milner 2009-04-20 11:21:56 EDT
Sorry, I meant to write :

I _have_ glibc.i686

Regards,

Steve
Comment 39 Steve Milner 2009-04-20 11:43:50 EDT
Sorry, I meant to write :

I _have_ glibc.i686

The exact details of the error is found in the config.log:

configure:3298: checking for suffix of object files
configure:3324: gcc -c -march=i686 -mtune=generic -fasynchronous-unwind-tables -g -O3   conftest.c >&5
conftest.c:1: error: CPU you selected does not support x86-64 instruction set
configure:3327: $? = 1

So it seems I can not cross compile from my x86_64 environment into a i686 environment.

I guess there must be some packages I need to add to get this to work.

Regards,

Steve
Comment 40 cje 2009-04-20 12:26:38 EDT
Steve, are you sure you still need glibc.i686?

i used to have to keep a bunch of i?86 stuff around (for things like adobe flash) but i did:

yum remove glibc-2.9-3.i686 glibc-devel-2.9-3.i386

on thursday (which removed those two plus 469 dependencies including some x86_64 -devel packages which i'll add back in later if i need them) and the system _seems_ fine so far.

anyway, it's good to know that the x86_64 rebuild is working again anyway.  :-)
Comment 41 cje 2009-04-21 09:26:57 EDT
looking at bug 212520 it would appear that either a) it's just not possible to cross-compile glibc or b) it might be possible using the workarounds mentioned in that bug.

hope that helps.  :-)
Comment 42 Steve Milner 2009-04-21 10:23:10 EDT
Sadly I need Skype which is only available as a binary 32 bit.

Regards,

Steve
Comment 43 cje 2009-04-22 16:36:22 EDT
well, our next option (short of getting the actual package updated in fedora proper) is, according to some recent comments on fedora-devel-list, using 'mock' - if you can find out what that is and how it works.

alternatively, create a VM, install 32 bit fedora on it and build it there.
Comment 44 Ulrich Drepper 2009-04-25 00:45:18 EDT
Upstream contains a change.
Comment 45 cje 2009-04-27 09:09:07 EDT
Ulrich, i _think_ changing it that way will mean that week numbering will be calculated from Sunday when it should be Monday.  So the DoW stuff might be right but week numbering will be broken.

Do you have a link to somewhere where Samuel has given his reasoning for using Sunday for week[2] or should i just email him direct?

he says "week[2] into always be 19971130, as glibc assumes this" - well, glibc's wrong then, isn't it?
Comment 46 cje 2009-04-27 13:26:53 EDT
i've tried building and installing just glibc-common with Samuel's patch and the gnome panel calendar appears to be okay - both DoW and WoY look correct to me.

does anyone know any other apps i can use to test the week numbering?
Comment 47 J Gallagher 2009-04-29 21:30:26 EDT
This is still not fixed in Fedora 11 Preview.

Select Language as 'English (United Kingdom)' on the gdm login screen and your gnome calendar has the first day of the week as Tuesday.

Please get the fix into the final release next month, it is a major annoyance for users over here in the UK.
Comment 48 cje 2009-04-30 05:44:27 EDT
looks like f11 preview has glibc-2.9.90-19
do a software update and you'll pick up glibc-2.9.90-22 which, i believe, contains the fix.  from the changelog:

- update from trunk
  - further localedef fixes 

i tried it out last night and it looked okay.
Comment 49 Kevin R. Page 2009-05-01 12:20:59 EDT
I can confirm it's fixed for me with F11 preview + glibc-2.9.90-22.i686

So the problem and fix are known - but we still need an update for F10.
Comment 50 J Gallagher 2009-05-10 16:42:10 EDT
I can confirm this is fixed in F11 preview, with glibc-2.9.90-22 from rawhide.

Thanks.
Comment 51 Stuart Rowan 2009-06-16 10:10:49 EDT
An update for FC10 would be very appreciated. My gnome clock applet is really annoying.
Comment 52 Lee Ball 2009-06-30 18:59:14 EDT
Is this just going to be ignored and work continued on Fedora 10?
Comment 53 Bjorge Solli 2009-07-01 07:04:08 EDT
I have about 3000 users, and we all find that this bug is not yet resolved just plain absurd. Please up this to urgent and high priority!

Regards
Bjørge Solli
senior engineer
Comment 54 Bug Zapper 2009-11-18 04:24:58 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 55 Lee Ball 2009-11-23 10:59:26 EST
How sad that this went an entire release without being fixed. I'm not sure what the situation was with Red Hat Enterprise Linux if this was fixed or not but I would certainly have hoped so if I were paying for support.
Comment 56 cje 2009-11-24 08:42:33 EST
Lee, i _think_ this is fixed, at least for fedora 11 and 12.  are you not seeing Monday as the first day of the week?

if so you might need to raise a new bug for that.  i think this one will probably be closed as soon as F10 becomes obsolete.
Comment 57 Lee Ball 2009-11-24 09:00:49 EST
(In reply to comment #56)
> Lee, i _think_ this is fixed, at least for fedora 11 and 12.  are you not
> seeing Monday as the first day of the week?
> 
> if so you might need to raise a new bug for that.  i think this one will
> probably be closed as soon as F10 becomes obsolete.  

Sorry, yes it is fixed for me now in Fedora 12, didn't upgrade to 11. I'm just saying its a shame the fix was never passed back down to Fedora 10.

I need to get around to reinstalling my work PC at some point, I usually run releases for a year at least, can't keep reinstalling your work PC all the time :)
Comment 58 Bug Zapper 2009-12-18 02:00:22 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.