934218 - TimeZone data files on bugzilla webheads is out of date

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Infrastructure, defect)

Description

[Alexander L. Slovesnik]

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

Comment 1

[:glob ✱]

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).

Comment 2

[Kendall Libby [:fubar] (he/him)]

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

[Shyam Mani [:fox2mike]]

(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

[Dave Miller [:justdave]]

(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

[Kendall Libby [:fubar] (he/him)]

(In reply to Dave Miller [:justdave] ([e-mail]) 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

[Dave Miller [:justdave]]

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

[David Lawrence [:dkl]]

(In reply to Dave Miller [:justdave] ([e-mail]) 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

Comment 8

[Dave Miller [:justdave]]

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?  :)

Comment 9

[:glob ✱]

(In reply to Dave Miller [:justdave] ([e-mail]) 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

[David Lawrence [:dkl]]

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

[:glob ✱]

(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 :)

Comment 12

[Alexander L. Slovesnik]

(In reply to Dave Miller [:justdave] ([e-mail]) 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

[:glob ✱]

(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

[Kendall Libby [:fubar] (he/him)]

> 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.

Comment 18

[Jake Maul [:jakem]]

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).

Comment 19

[Jake Maul [:jakem]]

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...

Comment 20

[Jake Maul [:jakem]]

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...

Comment 21

[Jake Maul [:jakem]]

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?

Comment 22

[:glob ✱]

(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.

Comment 23

[:glob ✱]

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.

Comment 24

[Jake Maul [:jakem]]

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.

Comment 25

[:glob ✱]

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

[:glob ✱]

after ashish restarted httpd on production web1 and web2 the warnings stopped :)

Comment 27

[Jake Maul [:jakem]]

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).

Comment 28

[:glob ✱]

(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.

Comment 29

[Jake Maul [:jakem]]

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?

Comment 30

[:glob ✱]

thanks jake -- looks good to me.

Comment 31

[Jake Maul [:jakem]]

All done!