| Summary: | Timezone info is out of date in glibc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rodrigo Severo <rodrigo> |
| Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo-bugs, hugues.fournier, nunoplopes, raybooysen, rmiranda |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch for the "glibc/timezone" directory to bring it up to date with tzdata and tzcode 2005n
Brings "glibc/timezone" up to date (changed orignal and final directories). tzdata.tar.bz2 The tz ebuild with a few modifications. |
||
|
Description
Rodrigo Severo
2005-10-17 05:04:47 UTC
*** Bug 109472 has been marked as a duplicate of this bug. *** Created attachment 70840 [details, diff]
Patch for the "glibc/timezone" directory to bring it up to date with tzdata and tzcode 2005n
Here is a patch to the "glibc/timezone" directory to bring it up to date.
If you are interested, I can prepare a similar patch for each tz release.
This patch used glibc-2.3.5-r2 ebuild as it's starting point.
Created attachment 70850 [details, diff]
Brings "glibc/timezone" up to date (changed orignal and final directories).
I've only changed the original and final directories of the diff command. The
real content is the same.
I believe it will be easier to apply the patch the way it is now.
Comment on attachment 70850 [details, diff]
Brings "glibc/timezone" up to date (changed orignal and final directories).
we're going to go the route that fedora is using at the moment ... that is,
we're going to break the timezone out into a sep package since it really is an
external package from glibc
Great idea. Any release dates? Please let me know if I can help. Created attachment 70894 [details]
tzdata.tar.bz2
give this a try ... it'll overwrite your glibc zoneinfo files, but that's ok as
long as you dont unmerge the package ;)
Created attachment 70942 [details]
The tz ebuild with a few modifications.
I am sending the tz ebuild with a few modifications:
1. changed name. I don't think neither tzdata nor tzcode are good names as this
ebuild effectivelly installs both. I am proposing simply tz. I think tzlib is
another good option. There might be other options. Please don't name it tzdata
nor tzcode.
2. modified patch. The prior patch didn't install the "right" timezones. That's
not glibc's behaviour.
3. modified ebuild. Included ~x86 in KEYWORDS.
This version is installed in my system and it seems to be ok.
> 1. changed name. I don't think neither tzdata nor tzcode are good names as reason to go with tzdata is that is what Fedora uses > 2. modified patch. The prior patch didn't install the "right" timezones. sounds good > reason to go with tzdata is that is what Fedora uses
Well, I can't tell why Fedora named it tzdata but please don't do it in Gentoo.
Either tzdata or tzcode would be misleading names.
maybe, but 'tz' is just obscure while 'libtz' doesnt apply since we dont install libtz 'timezone' or 'zoneinfo' might be ok > maybe, but 'tz' is just obscure while 'libtz' doesnt apply since we dont install libtz I agree. > 'timezone' or 'zoneinfo' might be ok I see the point of both. I vote for 'timezone' as it seems more descriptive. What will be the relation between 'glibc' and 'timezone' ebuilds? Should 'glibc' have a PDEPEND on 'timezone'? glibc will probably DEPEND/RDEPEND on this package I believe glibc can't DEPEND on this package (timezone?) as it would make timezone be installed before glibc. I am not sure about the behaviour of RDEPENDs. Do they get installed after the main package? Anyway I believe they better relation would be PDEPEND. glibc doesn't depends on timezone to run (which is the meaning of RDEPEND as I far as I can understand). timezone should be installed after glibc is installed (which is the precise meaning of PDEPEND as I understand it). BTW, to minimize the chances of unexpected behaviours, I believe that there should be added a comment (or warning) at the end of glibc installation stating that after an upgrade of glibc timezone should be reemerged to guarantee that the timezone info is properlly updated. Otherwise the user would get old timezone info (the one available in glibc) until there is another timezone package. The text could be something like: "Upgrading sys-libs/glibc usually downgrades timezone info. Please (re)emerge sys-libs/timezone." *** Bug 94088 has been marked as a duplicate of this bug. *** *** Bug 68403 has been marked as a duplicate of this bug. *** glibc-2.3.5-r3 and timezone-data now in portage *** Bug 110968 has been marked as a duplicate of this bug. *** Reminder: Summer time in 2006 Australia is incorrect, without this timezone-data. Incorrectly changes on 26 March 2006, URGENT? The change effects Melbourne, Sydney, Adelaide, Hobart and related zones. Info: http://www.lawlink.nsw.gov.au/lawlink/Corporate/ll_agdinfo.nsf/pages/community_relations_daylight_saving zdump -v /usr/share/zoneinfo/Australia/Adelaide |grep "2006" The output should contain "Sun Apr 2" not "Sun Mar 26" wrong forum for such concerns e-mail tz@elsie.nci.nih.gov Sorry for the confusion, the timezone data supplied by sys-libs/timezone-data-2006b (and upstream) is correct for Australia. The problem: STABLE series of gentoo's glibc does NOT install timezone-data AND does not have a correct timezone data for Australia. So unless Australians install the (currently) unstable timezone-data, their time will be wrong for a week from Sunday March 26th. I believe this matter may need urgent attention. (else end-user headaches) The timezone data for Australia has been fixed in Fedora and Ubuntu. And Windows via hotfix. :-) |
