python-dateutil will be updated to version 2.x and there may be changes that affect this package. If python-vobject will work with the newer python-dateutil, you can safely close this bug. If python-vobject really does require python-dateutil 1.5, please use Requires: python-dateutil15 for Fedora versions of the package until it can be updated.
It looks like python-dateutil broke backward compat in their rule._byweekday which break vobject backtrace: http://jenkins.cloud.fedoraproject.org/job/fedocal/456/console reported upstream: https://github.com/dateutil/dateutil/issues/24
I see you were going to work on the vobject side of this, pingou - any progress?
There has been some discussion on the vobject list, the project is basically looking for a new home and a new maintainer and might have found the later. So no actual progress yet but I'm trying to keep up :)
Created attachment 993440 [details] patch to change requires What do you think about something like this for the interim, pingou?
Are you really considering changing the path to require the correct dateutils?
If we really wanted to go this route, I would suggest using something along the lines of: https://github.com/fedora-infra/pkgdb2/blob/master/runserver.py#L4 But I still prefer to go the upstream route. One more question, iirc, there are unit-tests for vobject so maybe we could use those instead of adding our own, no?
If I understand it correctly, changing the path is the most effective way to ensure that the desired, known good version of the module will be imported when the system has multiple versions available. I'll happily defer to your judgment if there is a better way. I'm not familiar enough with vobject to comment on unit tests, just suggesting an interim solution that should allow python-dateutil to be updated without breaking python-vobject. I agree that an upstream solution would be best, and the only acceptable solution in the long term; for the short term, the patch is intended to allow python-vobject to persist as-is.
pingou: Do you means adding something like: -__requires__ = 'vobject==0.8.1c' +__requires__ = ['vobject==0.8.1c', 'python-dateutil == 1.5'] That should work, those binaries should get the right sys.path.
But I'm not sure if it'll work for dependent packages. $ repoquery --whatrequires python-vobject conduit-0:0.3.17-10.fc21.noarch dexter-0:0.18-9.fc21.noarch fedocal-0:0.5.1-4.fc21.noarch openerp-0:6.1-8.20131111_004905.fc21.noarch openerp7-0:7.0-6.20140109_002644.fc21.noarch python-carddav-0:0.4.1-6.fc21.noarch translate-toolkit-0:1.9.0-5.fc20.noarch trytond-calendar-0:2.6.1-4.fc21.noarch wuja-0:0.0.8-14.fc21.noarch So #c4 seems like a safer option.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #8) > pingou: Do you means adding something like: > -__requires__ = 'vobject==0.8.1c' > +__requires__ = ['vobject==0.8.1c', 'python-dateutil == 1.5'] > > That should work, those binaries should get the right sys.path. Yes that's what meant and this is likely the most elegant way to do it.
Yes, but does it work for, e.g. fedocal which does 'import vobject'?
I built python-dateutil with explicit Conflicts:python-vobject <= 0.8.1c-10 so that we can get some testing of the new dateutil. I hope you can build a new version of vobject soon.
Fixed in rawhide and f22