Reply
Thread Tools
Posts: 1,417 | Thanked: 2,619 times | Joined on Jan 2011 @ Touring
#1
I saw a comment about Maemo5 being off on its daylight savings switch on Israel Standard time, it has apparently been off daylight shift for a few weeks now while Israel is now switching with Europe.
 

The Following User Says Thank You to biketool For This Useful Post:
Posts: 1,100 | Thanked: 2,797 times | Joined on Apr 2011 @ Netherlands
#2
 

The Following 3 Users Say Thank You to ade For This Useful Post:
Posts: 31 | Thanked: 44 times | Joined on Jun 2010
#3
Or if you prefer to compile the timezone data for Israel yourself, it's pretty easy to do (it worked falwlessly for me):
  • First, to see your current timezone settings:
    Code:
    zdump -v Asia/Jerusalem | grep 2013
    The information is being read from /usr/share/zoneinfo/Asia/Jerusalem.
  • Assuming it's incorrect (still showing the switch to IST as occurring in September), download the new data from http://www.iana.org/time-zones, and place it in some temporary directory $TMP, unzip it (note that the contents will be unzipped directly into the current directory, no subdirectory will be created). The new information you need is in the extracted 'asia' file.
  • Compile the new information into the format needed by the system (the following has to be done as root):
    Code:
    zic -d $TMP_OUT asia
    where 'asia' is the said file containing the new information, and $TMP_OUT is the directory in which the compiled data wil be placed (if $TMP_OUT doesn't exist, it will be created).
    This will create an Asia directory under $TMP_OUT, and inside that directory will be, among others, a 'Jerusalem' file. Replace /usr/share/zoneinfo/Asia/Jerusalem with this new copy (keep a backup of the original, if you want to be safe).
  • That's it! issuing 'date' will now show the correct time. In order for the clock to be updated, I rebooted at this point, though I imagine that there's a way to update the clock without a reboot, but I don't know how.

NOTE: Better to compile the new information on the n900 itself. The compiled files on my desktop system are much larger that those on the n900, and when I compiled the new data on my desktop, it, too, produced larger files. Compiling it on the n900 produced files of the same size as the originals.

Hope this helps!
Dov
 

The Following 3 Users Say Thank You to dovf For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#4
Is there (a) specific debian package(s) on our N900s responsible for the time zone data? If so, perhaps it might be appropriate for the CSSU to maintain an up-to-date one?
 

The Following 3 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,100 | Thanked: 2,797 times | Joined on Apr 2011 @ Netherlands
#5
Originally Posted by Mentalist Traceur View Post
Is there (a) specific debian package(s) on our N900s responsible for the time zone data? If so, perhaps it might be appropriate for the CSSU to maintain an up-to-date one?
It is located in the libc6 package
No idea why Nokia put it there. It makes updating more complex.
I have talked with Freemangordon about this. As long as libc6 is not in CSSU, there will probably be no update. I don't know if splitting these parts is an option.
 

The Following 3 Users Say Thank You to ade For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#6
Originally Posted by ade View Post
It is located in the libc6 package
No idea why Nokia put it there. It makes updating more complex.
I have talked with Freemangordon about this. As long as libc6 is not in CSSU, there will probably be no update. I don't know if splitting these parts is an option.
Oooohhh. That's not Nokia's fault. I think that's standard (although somewhat dumb) practice - libc6 has timezone rules hardcoded in as I understand it, and many many things that use it at one level or another rely on it for their timezone rules.

But at least it looks from the description in these posts, like they're separate files, not part of the actual libc6 binary/binaries.

I think it would be cleaner to have them as separate packages honestly. But it should also be possible to upgrade the libc6 package WITHOUT upgrading the libc6 binary itself... Idk, I'm not an expert, but there's no inherent technical reason why it's impossible to upgrade just the timezone parts of the package and push out an upgrade like that, without breaking programs depending on our old libc6 binary.
 

The Following 2 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#7
a lot of distros split these now into seperate packages. may be worth looking at some of their methods, particularly there method of handling dependancies between the two.

if its just the files in zoneinfo, would it be easier to build the new files as mentioned above to a temp directory, to integrate into new package. Extract libc6 to remove old zoneinfo files, edit config and rules etc, then rebuild package, keeping binaries intact.

not sure if divert could help as a solution for non cssu.
 

The Following 2 Users Say Thank You to Android_808 For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#8
Took some time to take a quick look at Arch. They split zoneinfo off into tzdata package. glibc then depends on that.

The PKGBUILD for the file makes use of a package() section, which calls make install and installs some config files etc. At the moment I don't know what is missing/added to prevent zoneinfo files being installed.

tzdata pulls in files from iana, including leap seconds, and creates the files as part of its package() process. Looks relatively straight forward to replicate. https://projects.archlinux.org/svnto...ackages/tzdata
 

The Following User Says Thank You to Android_808 For This Useful Post:
Reply

Tags
maemo 5, timezone


 
Forum Jump


All times are GMT. The time now is 06:01.