Bug 270
Summary: | RH 5.2 has not quite fixed timezone bug | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Bryce Nesbitt <bryce> |
Component: | timeconfig | Assignee: | David Lawrence <dkl> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 5.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1998-12-03 22:00:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bryce Nesbitt
1998-12-02 20:37:52 UTC
Are you using glibc or libc5 netscape? We use both 4.07 and 4.5b1, with a random assortment of libc5 and glibc. Here's one known to have the problem at least with RH5.1: fedora:/usr/local/netscape-4.07> ldd netscape libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40003000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40046000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4004e000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40062000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40074000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40081000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008c000) libdl.so.1 => /lib/libdl.so.1 (0x40123000) libc.so.5 => not found libg++.so.27 => not found libstdc++.so.27 => not found libm.so.5 => not found libc.so.6 => /lib/libc.so.6 (0x40126000) /lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x00000000) fedora:/usr/local/netscape-4.07> The symptom of the bug is that Netscape tags email in GMT rather than the local timezone. -Bryce libc5 binaries will have this problem. (incidentally, those aren't the ones we ship.) The reason we can't really fix this is that RPM can't replace the /usr/lib/zoneinfo directory with a symlink reliably on an upgrade. Gee, then it sounds like an RPM bug. Why should RPM not have the ability to set/fix symlinks? The rpm creator could specify the action to take if either another symlink or directory was found the same spot. FYI, tzset actually checks /etc/localtime in glibc (the man page is wrong...). /usr/share/zoneinfo/localtime is a link to this. (It's so you can have shared zoneinfo but different localtimes for different machines.) As for the RPM issue, to do it right you'd have to recursively descend into the directory, and make sure every file is owned by the package you're upgrading, etc. (Replacing symlinks isn't a problem - replacing a directory with a file/symlink is.) It's being looked at for a future version of RPM, but it's messy. |