Description of problem:
The pytz packages in Fedora, and in particular EPEL ones, are getting out-of-date.
The latest upstream version mentioned in:
Version-Release number of selected component (if applicable):
Fedora and EPEL branches.
I don't see a reason not do do this in rawhide, and even F-12 and F-13, but I'm not sure about EPEL.
Jef, any objections?
As long as you keep the patch in place which preferentially uses the system wide tzdata packages for timezone information and whatnot instead of looking at the information pytz includes.
Ah crap..it looks like that was only patched in the Fedora versions. The fedora versions don't even include timezone zoneinfo content anymore as its redudant info.
What needs to happen is the pytz version in EPEL needs to be patched to how its being shipped in Fedora to depend on tzdata...regardless of what version of pytz is actually shipped.
The point of this patch is two-fold. 1) reduce duplicated content on disk..
2) reduce the number of unnecessary package updates when zoneinfo changes occur. If we always rely on tzdata as for zoneinfo..then we don't have to scramble update zoneinfo in other oddball places to match.
Look at pytz_zoneinfo.patch in the pytz fedora packaging cvs or git or whatever is being used this week :->
Is there a compelling need to push this update for bugfixes in pytz other than updated zoneinfo?
(In reply to comment #2)
let me add....
1) bump rawhide and f13 if you want...make sure that patch is still applicable...and keep the zoneinfo stripped out.
2) for f12/f11 there needs to be a compelling reason to update other than zoneinfo. Its probably safe to do..but its also probably entirely unncessary unless there is a specific bug that needs to be addressed that is not associated with the zoneinfo content as provided by tzdata.
3) EPEL needs to be updated to at least depend on tzdata regardless of the pytz version in EPEL. It would be enough just to apply the patch and strip the content without bumping the pytz in EPEL...but I doubt there's been an API change so its safe to version bump. tzdata does get updated in RHEL/CentOS based on zoneinfo changes I believe.
I put 2010h in rawhide, I think it's a bit late for f13. I agree that there's nothing compelling an update for f12 and f11. WRT EPEL, do you think I can just update to 2010h and keep the same patch, do avoid having to re-do the patch recreation I had to do for 2010h? The alternative would be to bump EL-5 to 2008i and use that patch.
whoa.. you confused me with the multiple patch references in the EPEL stuff.
Let me look over the EPEL situation at lunch today.
If we can get EPEL packaging patched to using the system wide tzdata that would be best... as tzdata is provided by RHEL already.
Sorry, I was essentially proposing to update EL-5 to what was in rawhide this morning, a patched 2008i, or what's there now, a patched 2010h. The patch had to be updated for the new version, that's all.
either one is probably fine. Does 2010h provide any actual bugfixes or API changes in the python code or is it just tzinfo content updates? if its just content updates... it really doesn't matter....becuase we nuke the content and rely on tzdata.
The last two changelog entries:
- Ensure API can accept Unicode strings (Bug #96957)
- Fix test_zdump tests and bugs the fixed tests picked up, including
the fix for Bug #427444.
So, possibly. I vote 2010h.
You can probably push this to F13 as well.
pytz-2010h-1.el5 has been submitted as an update for Fedora EPEL 5.
pytz-2010h-1.fc13 has been submitted as an update for Fedora 13.
pytz-2010h-1.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update pytz'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/pytz-2010h-1.el5
pytz-2010h-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
pytz-2010h-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.