Bug 1126521

Updating python3-dateutil as well.

This should have been announced, I'm getting broken deps emails because of this...

If I read http://labix.org/python-dateutil correctly:
> Ported to Python 3, by Brian Jones. If you need dateutil for Python 2.X, please continue using the 1.X series.

We should not have updated dateutil to 2.2 from 1.5.

We're ending up with 3 packages
* py-dateutil -> just went from 1.5 to 2.2 (ie py2 to py3, no announce... thanks!)
* py3-dateutil -> py3 version, version 2.2
* py-dateutil15 -> py2 version 1.5 and it's at release 5 while dateutil was at release 7 (so different patches??)


We're doing something wrong here

I wasn't aware of anything requiring an older version, and there wasn't a soname change or anything, my apologies.  I've bumped the Epoch and reverted.

Note that dateutil website has not been updated since 2.0 release.
According upstream, dateutil 2.1+ works fine under python 2.6+ & 3.2+ using the same codebase
http://bazaar.launchpad.net/~dateutil/dateutil/trunk/view/head:/NEWS

The website is clearly not clear :)

I've tested fedocal with dateutil 2.2, the tests seem to run fine, so with some spec mojo I guess I can make fedocal work with either 1.5 or 2.2 (maybe 2.1 but clearly not 2.0 apparently).

Thanks for reverting :)

Should we port the question to the fedora python list or maybe the devel list? Announce it properly and see if we can get the compat package python-dateutil15 up-to-date and then update the python-dateutil to 2.2.

If python-dateutil is now working on py2 and py3, maybe we should drop as well the py3-dateutil package (and add the appropriate Provides in py-dateuil). What do you think?

(In reply to Pierre-YvesChibon from comment #6)
> The website is clearly not clear :)

[snip]

> If python-dateutil is now working on py2 and py3, maybe we should drop as
> well the py3-dateutil package (and add the appropriate Provides in
> py-dateuil). What do you think?

The incompatibility was the reason for splitting py2 and py3 for the dateutil module. See bug #810859 #comment3

If it works again with a single code base, we can merge it back to python-dateutil again.

I'm not sure, I'll leave that for Jef to decide.  Additonally, I'm working on fixing up fedocal and python-django-tastypie, which need adjustment to account for python-dateutil's Epoch bump.

If dateutil2.2 works with python2, and a python-dateutil15 package exists.
The one patch in python-dateutils doesn't have to go into python-dateutils15 for epel6. Otherwise, they appear to be functionally identical.  

If the blocker on getting the 2.2 bump here is simply changing requires on the 57? packages that depend on python-dateutil to point to a different package that provides the same code, let's please do that.  I'm willing to drive the effort with announcements, bz tickets, and spec patches as pingou suggested - if the maintainers of the two packages are game.  

(Of course, if there's something I'm missing here, please let me know)

Did you need any input from me here?

(In reply to Rahul Sundaram from comment #10)
> Did you need any input from me here?

Yes,actually - how would you feel about carrying the system tz patch in python-dateutil15, for F21 at least? That would provide continuity for packages changing to use it as a compat dependency.

That would be fine especially if it had a time limit to it.

As a side note, it looks like switching upstream to https://github.com/dateutil/dateutil/, where 2.4.0 has been released, will be a good idea.  The patch doesn't apply cleanly, I'll try my hand at it.

The patch is beyond my skillset, sorry.  I do see this in NEWS, however:

   db52fc8e (Yaron de Leeuw   2014-11-29 18:04:03 +0200  25) - New maintainer, together with new hosting: GitHub, Travis, Read-The-Doc

(In reply to Pete Travis from comment #14)
> The patch is beyond my skillset, sorry.  I do see this in NEWS, however:
I'll take the patch then.

It seems that the patch is not actually necessary [1]. I asked for clarification ibidem.

[1] https://github.com/dateutil/dateutil/issues/11

Koji scratch build of python-dateutil-2.4: http://koji.fedoraproject.org/koji/taskinfo?taskID=8689292

To move this forward, we need to update to 2.4 in rawhide, and shake out any bugs.

Current plan:
1. do a scratch build (see link above)
2. test locally
3. do a rawhide build and fix any bugs which show up
4. retire python3-dateutil
5. build python3-dateutil from python-dateutil srpm

I'll proceed with 3 in a few days if nobody complains and no significant problems are found.

(Note: build above includes a patch equivalent to that from #c11.

Better koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8689479
Koji build with python3 subpackage: http://koji.fedoraproject.org/koji/taskinfo?taskID=8689481

python-dateutil-2.4.0-2.fc22 and fc23 built.

Everything is done here. If any bugs pop up, they'll have to be dealt with in the normal fashion.