Closed
Bug 934218
Opened 11 years ago
Closed 10 years ago
TimeZone data files on bugzilla webheads is out of date
Categories
(bugzilla.mozilla.org :: Infrastructure, defect)
bugzilla.mozilla.org
Infrastructure
Tracking
()
RESOLVED
FIXED
People
(Reporter: unghost, Assigned: nmaul)
References
Details
(Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/229] )
STR: 1) Open https://bugzilla.mozilla.org/userprefs.cgi and select Europe/Moscow timezone 2) Add comment to bug Expected result: Timestamp in bug comment is 2013-11-03 15:59:12 MSK Actual result: Timestamp in bug comment is 2013-11-03 14:59:12 MSK
the timezone data files on our bugzilla webheads are out of date. on my dev system (fedora 19), DateTime::TimeZone::Europe::Moscow was built from olsen data dated 2013d (from the perl-DateTime-TimeZone-1.60-1.fc19.noarch package). on allizom (rhel6), DateTime::TimeZone::Europe::Moscow (/usr/share/perl5/DateTime/TimeZone/Europe/Moscow.pm) was built from olsen data dated 2009u (from the perl-DateTime-0.5300-1.el6.x86_64 package).
Assignee: nobody → server-ops-webops
Component: General → WebOps: Bugzilla
Product: bugzilla.mozilla.org → Infrastructure & Operations
QA Contact: nmaul
Summary: Timestamp in bug comments is 1 hour behind for Europe/Moscow timezone → TimeZone data files on bugzilla webheads is out of date
Version: Production → other
Comment 2•11 years ago
|
||
perl-DateTime-0.5300-1.el6.x86_64 is the latest version available from RH (who would want a newer version?!), so we'll need to pull this from a different repo. Given how intertwined perl modules tend to be, do we have a process for updating single modules? The version installed also doesn't appear to offer any of the tools in the newer versions to (re)build TZ data. Naturally.
Comment 3•11 years ago
|
||
(In reply to Kendall Libby [:fubar] from comment #2) > perl-DateTime-0.5300-1.el6.x86_64 is the latest version available from RH > (who would want a newer version?!), so we'll need to pull this from a > different repo. Given how intertwined perl modules tend to be, do we have a > process for updating single modules? > > The version installed also doesn't appear to offer any of the tools in the > newer versions to (re)build TZ data. Naturally. Can we see if there's an upstream bug to fix this?
Comment 4•11 years ago
|
||
(In reply to Kendall Libby [:fubar] from comment #2) > Given how intertwined perl modules tend to be, do we have a > process for updating single modules? If there's a newer version in either rpmforge or epel, we can just install it.
Comment 5•11 years ago
|
||
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #4) > If there's a newer version in either rpmforge or epel, we can just install > it. /sadtrombone epel doesn't even HAVE an rpm for RHEL6, and rpmforge is at the same version as RHN.
Comment 6•11 years ago
|
||
The fact that rpmforge even has it mean they're already overriding what's in RHEL. They can probably be easily convinced to upgrade it.
Comment 7•11 years ago
|
||
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #6) > The fact that rpmforge even has it mean they're already overriding what's in > RHEL. They can probably be easily convinced to upgrade it. I made an honest effort of this today and fell into a bottomless hole of dependencies. Latest perl-DateTime-TimeZone requires a much newer perl-DateTime which requires a slew of other deps (Moose) that are not part of RHEL/EPEL. If you could convince rpmforge to update theirs then that would make our lives easier. Otherwise I can come back to this when I get my other higher priority stuff whittled down. We could go back to earlier versions of perl-DateTime-TimeZone that at a minimum fix the Europe/Moscow issue and maybe get something that is not so particular about dep versions. https://metacpan.org/changes/distribution/DateTime-TimeZone dkl
Updated•11 years ago
|
Comment 8•11 years ago
|
||
ok, why does this module even have an internal database for this stuff instead of using the system-wide timezone data (which gets updated frequently, I might add) And who in the hell decided to make a system-utility-level Perl module depend on Moose? :)
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #8) > And who in the hell decided to make a system-utility-level Perl module > depend on Moose? :) i don't see moose in the dep-tree for DateTime, either on cpan or in fedora's packages. http://deps.cpantesters.org/?module=DateTime%3A%3ATimeZone&perl=5.10.1&os=Linux http://deps.cpantesters.org/?module=DateTime&perl=5.10.1&os=Linux
Comment 10•11 years ago
|
||
perl-DateTime-TimeZone-1.63-1: Transaction Check Error: file /usr/share/man/man3/DateTime::TimeZone.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::Catalog.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::Floating.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::Local.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::Local::Unix.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::Local::VMS.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::OffsetOnly.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::OlsonDB.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 file /usr/share/man/man3/DateTime::TimeZone::UTC.3pm.gz conflicts between attempted installs of perl-DateTime-TimeZone-1.63-1.el6.noarch and perl-DateTime-1:0.5300-1.el6.x86_64 Building perl-DateTime-1.03-1: error: Failed build dependencies: perl(DateTime::Locale) >= 0.41 is needed by perl-DateTime-1.03-1.el6.x86_64 perl(DateTime::TimeZone) >= 1.09 is needed by perl-DateTime-1.03-1.el6.x86_64 Installing perl-DateTime-Locale-0.45-1: Error: Package: perl-DateTime-Locale-0.45-1.el6.noarch (/perl-DateTime-Locale-0.45-1.el6.noarch) Requires: perl(MooseX::ClassAttribute) So: perl-DateTime-TimeZone-1.63 => perl-DateTime-1.03 => perl-DateTime-Locale-0.45 => perl-MooseX-ClassAttribute => perl-Moose-Role What if we just update the timezone db in the current perl-DateTime-0.5300 package? dkl
Comment 11•11 years ago
|
||
(In reply to David Lawrence [:dkl] from comment #10) > Error: Package: perl-DateTime-Locale-0.45-1.el6.noarch > (/perl-DateTime-Locale-0.45-1.el6.noarch) > Requires: perl(MooseX::ClassAttribute) that's really weird, because the module on cpan doesn't require moose: http://deps.cpantesters.org/?module=DateTime%3A%3ALocale&perl=5.10.1&os=Linux > What if we just update the timezone db in the current perl-DateTime-0.5300 > package? that sounds reasonable :)
Reporter | ||
Comment 12•11 years ago
|
||
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #8) > ok, why does this module even have an internal database for this stuff > instead of using the system-wide timezone data (which gets updated > frequently, I might add) Perhaps, it would make sense to file bug against Bugzilla to make it use system-wide timezone data instead of timezone data in perl-DateTime-TimeZone?
Comment 16•11 years ago
|
||
(In reply to Alexander L. Slovesnik from comment #12) > Perhaps, it would make sense to file bug against Bugzilla to make it use > system-wide timezone data instead of timezone data in perl-DateTime-TimeZone? that would require writing our own cross-platform datetime and timezone modules. that sounds counter-productive, and a much larger task when compared with updating an installed perl module.
Comment 17•11 years ago
|
||
> What if we just update the timezone db in the current perl-DateTime-0.5300
> package?
parse_olson should do the trick, but it isn't actually a part of the package (or at least our version). I found a version of the nearly the same vintage as our perl-DateTime and am pushing out one module it wants (file-find-rule). Will see what it takes to rebuild the files once it's in place.
Assignee | ||
Updated•10 years ago
|
Assignee: server-ops-webops → nmaul
Assignee | ||
Comment 18•10 years ago
|
||
Okay so, to recap: The reason this is non-trivial (and likely why RHEL and other large repos like EPEL and rpmforge haven't updated it) is that upstream split the DateTime module into 3 separate packages... DateTime, DateTime-Locale, and Datetime-TimeZone. Hence its not a simple thing to package because it plays hell with dependency tracking. On top of that, the dependencies have actually changed over time (see comments above).
Assignee | ||
Comment 19•10 years ago
|
||
I was able to package a somewhat newer (but not "new") version. I've installed it on web1.bugs.scl3, but nowhere else and have not restarted anything, so it's probably not in effect. Previous: perl-DateTime-0.5300 - contains DateTime-0.53 and DateTime::TimeZone-1.08. Olson 2009u, dated 2009-12-28. Newer: perl-DateTime-0.7000 - containts DateTime-0.70 and DateTime::TimeZone-1.34. Olson 2011g, dated 2011-04-25. This is considerably newer (about 1.5 years), though obviously still way out of date. Current is DateTime::TimeZone-1.69, released 2014-05-13 containing IANA 2014c. So, still ~3 years behind. Still, 3 is better than 4.5, eh? I'm still trying to go higher...
Assignee | ||
Comment 20•10 years ago
|
||
Newer yet: perl-DateTime-0.70-2 - contains DateTime-0.70. this depends on perl-DateTime-TimeZone and perl-DateTime-Locale, which are also packaged! Olson 2011l, dated 2011-10-10. This is the first time I've successfully packaged one of the "split" packages. I did this by taking source RPMs from Fedora 19 and rebuilding them on RHEL6. They don't build out of the box on RHEL6... you have to have a newer version of DateTime::TimeZone already installed than RHEL6 comes with. That requires the intermediate step of installing DateTime-0.7000 from comment 19, which was itself built from Fedora *16*. Though, now that it's packaged, it's probably feasible to go straight to this newer version. Still about 2.5 years behind...
Assignee | ||
Comment 21•10 years ago
|
||
Yay! I have successfully packaged the following: perl-DateTime-1.03 (from Fedora 20) perl-DateTime-TimeZone-1.69 (from Fedora 21 - not even out yet!) perl-DateTime-Locale-0.45-8 (from Fedora 20) This is the current version of TimeZone and Locale (the latter seems to change *very* rarely). It's a bit older on the main package, about a year out of date. However I was not able to easily package a newer version... 1.10 is in Fedora 21, but has missing compile-time dependencies at least 2 levels deep, and I didn't dig further than that. I have updated web[12].bugs.scl3.mozilla.com with these packages. Is there some way we can validate that this is fixed on those two nodes, before rolling it out to all of them?
Flags: needinfo?(glob)
Comment 22•10 years ago
|
||
(In reply to Jake Maul [:jakem] from comment #21) > I have updated web[12].bugs.scl3.mozilla.com with these packages. did you mean web[12].stage.bugs.scl3.mozilla.com, or has this gone straight to production? if it's on stage, then i can run some tests. ideally web[34].stage.bugs.scl3.mozilla.com.
Flags: needinfo?(glob) → needinfo?(nmaul)
Comment 23•10 years ago
|
||
this has generated a *lot* of warnings on production: Loaded DateTime::TimeZone::Asia::Singapore, which is from an older version (2014c) of the Olson database than this installation of DateTime::TimeZone (2009u). please back out this change from production, and instead deploy to bugzilla.allizom.org so we can test.
Assignee | ||
Comment 24•10 years ago
|
||
Huh, very strange... that error is backwards. Well in any case, I've backed it out from the 2 prod nodes and installed it on the 2 stage nodes. I've also restarted Apache on the stage nodes, which may or may not have any effect.
Flags: needinfo?(nmaul)
Comment 25•10 years ago
|
||
now production is throwing the reverse error: Loaded DateTime::TimeZone::Asia::Bangkok, which is from an older version (2009u) of the Olson database than this installation of DateTime::TimeZone (2014c).
Comment 26•10 years ago
|
||
after ashish restarted httpd on production web1 and web2 the warnings stopped :)
Updated•10 years ago
|
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/229]
Updated•10 years ago
|
Component: WebOps: Bugzilla → Infrastructure
Product: Infrastructure & Operations → bugzilla.mozilla.org
Assignee | ||
Comment 27•10 years ago
|
||
Can you let us know if this is working on the stage nodes, or what errors you're getting there? If it doesn't work, there are the version in-between this latest one and the one that's installed on prod that we can also try (see comments 19,20,21).
Flags: needinfo?(glob)
Comment 28•10 years ago
|
||
(In reply to Jake Maul [:jakem] from comment #27) > Can you let us know if this is working on the stage nodes, or what errors > you're getting there? thanks for working on this jake - as far as i can tell this is working without issue on stage.
Flags: needinfo?(glob)
Assignee | ||
Comment 29•10 years ago
|
||
I did this carefully on web1.bugs.scl3... drained in ZLB, upgraded, stopped apache, looked for any 'perl' or 'httpd' procs, and then started it back up and added it back to the ZLB. So far so good. Not seeing any errors on the system itself, and nothing in errormill.mozilla.org AFAICT. Waiting for confirmation before proceeding, however. :glob?
Flags: needinfo?(glob)
Assignee | ||
Comment 31•10 years ago
|
||
All done!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•