Learn more about these different git repos.
Other Git URLs
After commit 0681812, an issue similar to #231 has popped up again for build notifications. RPMs seem to make it through the builds properly.
Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1219, in runTask response = (handler.run(),) File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 162, in run return koji.util.call_with_argcheck(self.handler, self.params, self.opts) File "/usr/lib/python2.7/site-packages/koji/util.py", line 205, in call_with_argcheck return func(*args, **kwargs) File "/usr/sbin/kojid", line 4779, in handler creation_time = koji.formatTimeLong(build['creation_time']) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2795, in formatTimeLong localtime = time.mktime(time.strptime(formatTime(value), '%Y-%m-%d %H:%M:%S')) File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2781, in formatTime dotidx = value.rfind('.') AttributeError: DateTime instance has no attribute 'rfind'
It looks xmlrpc_client DateTime object is not handled properly in the formatTime function. I think this is a line that causes a problem:
value = datetime.datetime.strptime(value.value, "%Y%m%dT%H:%M:%S")
It executes when value is an instance of xmlrpc_client.DateTime. After that code looks for a dot in the string, but as it can be seen the value is not a string. Replacing above line with:
value = datetime.datetime.strptime(str(value.value), "%Y%m%dT%H:%M:%S")
or
value = str(datetime.datetime.strptime(value.value, "%Y%m%dT%H:%M:%S"))
may fix the problem.
Another possibility is that the above line doesn't execute at all (for some reason), so maybe adding value = str(value) before dotidx = value.rfind('.') will fix the problem.
Related StackOverflow post: https://stackoverflow.com/questions/32989945/python-xmlrpclib-changes-datetime-object-to-datetime-instance-on-transmit
Yet another possibility (as suggested in the StackOverflow post) would be to add use_builtin_types=True to the call of ServerProxy(...)
I would try to recreate this problem and fix it locally, but I am new to this and have no idea how to do it, so I can only guess what's the problem and fix is, but I hope it'll help a bit.
This should be fixed by PR #624
Metadata Update from @tkopecek: - Issue set to the milestone: 1.15
Metadata Update from @tkopecek: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.