On Thu, Oct 03, 2013 at 09:27:53AM -0700, Daniel Schepler wrote: > On Thursday, October 03, 2013 02:43:03 PM Nikolaus Schulz wrote: > > This is really weird. Because what the test code there does is > > something like this: > > > > s = 24 * 60 * 60 > > time_msg = time.time() - s > > time_now = time.time() > > assert time_message + s < time_now > > > > So if this fails, time_msg == time_now. But the resolution of the clock > > should be good enough to prevent that from happening. What do you get > > on your system if you run > > > > $ python2 -c 'import time; print time.time() == time.time()' > > > > If that should happen to print "False", it would be cool if you could > > apply the attached patch and run ./test_archivemail once more. > > > > You can do this in the unpacked source bypassing all the packaging > > wrappers, they make no difference. > > I just tried running that python command line 10 times -- I got True 5 times > and False 5 times. As for trying the test_archivemail patch, that will > probably have to wait until this evening.
Wow, that outcome was unexpected. Your system clock is not precise enough to return strictly increasing wall clock times for quick successive calls to time.time(). And if two calls return the same time, this will indeed break the archivemail test suite. Testing my patch should not be necessary, thanks. It is just adding diagnostic output to debug this problem, and I think we have successfully identified the cause for this. Thanks for testing! Actually uploading a fixed package will have to wait until I return from holidays, though, so it won't happen before 20th October. Nikolaus -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
