Forum for the FireGPG's extention. (!Don't post too links or wait we unban your, akismet is very aggressive)
You are not logged in. Please login or register.
I've been playing around with the source tarball for firegpg, and i noticed that the timestamps for most of the locale files seem to be: 2038-01-19 03:14:07
(this is the wrap-around date for time_t, so i suspect a bug or something). It seems to be this way within chrome/firegpg.jar (inside firegpg.xpi) as well.
Could this be cleaned up somehow? It causes quite a bit of unnecessary warnings. Should i file it as a bug report?
Locate haven't any timestamps, to let's svn update them each time I update locates.
I won't change anything for this, it's just a warning...
I agree, it's not a hard error. But to be clear, it's not just a warning either. It's actually 330 warnings each time the tarball is unpacked., which is a lot of noise. It would be one thing if the timestamps were just missing (i don't know how the tar format would represent that), but it looks to me like the timestamps are actually, specifically, wrong.
It seems like there is an obvious semantic choice for what the timestamp for any given locale should be: just the date that you last updated it, no? Is there any reason not to do that, if it's possible?
Can you describe how you update the locales? Maybe i can help find a way to get the timestamps set to a reasonable value with no extra inconvenience for you. I'd like to help!
I create a zip widhout date. When zip is extracted, unzip seem to set the date to 2038. This is very useful (I don't have to make a touch locates/*/* for make svn detect changes in locates).
Do you extract our tarball every day ? Best way to get FireGPG's source is svn I think, to have the very last update...
I'm trying to create a maintainable build process for firegpg for debian (and its derivatives). The build process involves unpacking the tarball, as as it is the canonical source i'm working from. Having extra noise in the build process obscures real errors which i'd rather know about.
Won't svn detect changes based on the contents of the directory, not just the timestamps? Or even if it doesn't, wouldn't having the proper timestamps (e.g. right now) be sufficient for your purposes of alerting svn of the changes?
tar xvf firegpg.tar.gz | grep -v 2038-01-19 :]
> Won't svn detect changes based on the contents of the directory, not just the timestamps?
No, he check timestamps before (for performances I guess).
Btw there is already someone who maintain the debian package of firegpg, did you contact it ?
I've contacted him a couple times this week, but i've gotten no response yet.
The firegpg package was just recently removed from debian for being out-of-date and insecure, and i'm trying to rectify that.
While i understand your suggestion of unpacking things while deliberately ignoring certain errors, much of the automated build processes where an updated package would get rebuilt in debian do not give me that level of control. However, even if i did have that level of control, i think i woudn'td want to do it that way; the problem is that the timestamps are erroneous, and it makes more sense to me to correct them than to mask the warnings that they're clearly wrong.
how do you create a zip file without a date in the first place? i could find no such option in zip(1).
> The firegpg package was just recently removed from debian for being out-of-date and insecure, and i'm trying to rectify that.
That good.
> how do you create a zip file without a date in the first place? i could find no such option in zip(1).
I create it with a php class.
Anyways, if I change anything it's will be for the next release, who will be 'very later', I'm too busy to change anything for the moment. You should create a ticket on bugs.getfiregpg.org and wait for the next release 
I just filed task 269, thanks!
If you point me toward the PHP code you use to generate the locales, it's possible that i could give you a patch so you don't have to think about it any more.
Thanks for directing me to it.
I've just created a patch for the CreateZipFile class, and alerted the author of the original class so that they can incorporate it so that future users don't get the weird timestamps.
Feel free to apply that patch to your locale generation system; it should set the zipfile elements to the current timestamp by default.
Let me know if you have any trouble.
Patch applied and working, thanks !
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 2 official extensions. Copyright © 2003–2009 PunBB.